| brians | 343bc11 | 2013-02-10 01:53:46 +0000 | [diff] [blame^] | 1 | [General] |
| 2 | Check the logs! Very few things will fail without putting something in the logs. |
| 3 | If they do, that is a bug unless our code is never getting run (there are |
| 4 | innumerable ways that could happen, but it generally doesn't). |
| 5 | To check the logs, run `LogDisplayer` if `BinaryLogReader` has been started or |
| 6 | just run `LogStreamer` if you want to do simple testing without writing logs |
| 7 | to a file. See `LogDisplayer --help` for options. |
| 8 | All of the binaries get put in the same place. That is |
| 9 | src/out_atom/Default/outputs on the build machine and |
| 10 | /home/driver/robot_code/bin on the fitpc. |
| 11 | |
| 12 | [Startup] |
| 13 | Low level startup errors often end up in /aos_fatal_error.* on the cRIO and |
| 14 | /tmp/aos_fatal_error.* under linux. Also helpful are the /tmp/starter*_std* |
| 15 | files (if the standard start scripts are being used) and |
| 16 | aos/crio/bin/netconsole.sh for reading cRIO stdout and stderr. |
| 17 | If lots of the /tmp/starter_*std* files (with different numbers) are being |
| 18 | created, that means that starter_exe is dying constantly. |
| 19 | |
| 20 | [Anything Not Running] |
| 21 | Check starter_exe's log messages. They might mention that it is constantly dying |
| 22 | on startup and being restarted. |
| 23 | |
| 24 | [Control Loop(s) Not Working] |
| 25 | Are robot_state messages going out? An aos::JoystickInput (often JoystickReader) |
| 26 | should be sending them. |
| 27 | Is it being fed goal messages? |
| 28 | Is it getting position messages? |
| 29 | Is something looking at the output and doing something useful with it? |
| 30 | |
| 31 | [No Driver Station Packets] |
| 32 | Check to make sure that JSR (a cRIO-side task) is saying that it's sending |
| 33 | messages. Also check JoystickReader (or whatever inherits from |
| 34 | aos::JoystickInput) is running and see if it's receiving anything. |
| 35 | |
| 36 | [Attaching a Debugger] |
| 37 | In order to make attaching a debugger very useful, you have to compile the code |
| 38 | with debugging symbols. The way to do that is to modify the appropriate |
| 39 | build.sh to pass "yes" instead of "no" as an argument to the aos build.sh. You |
| 40 | have to modify a .gyp file (touching it is sufficient) to get it to use the |
| 41 | new build flag. |
| 42 | Attaching GDB to an existing robot code process works like normal (you have to |
| 43 | root first because that's what all of the code currently runs as). |
| 44 | If a process is dying repeatedly, the easiest way to debug it is to kill |
| 45 | starter_loop.sh and (it has to be after that) starter_exe. After doing that, |
| 46 | NOTHING will get restarted (including the normal restart after changing a |
| 47 | binary) so that you can start a process under GDB like usual (shouldn't need |
| 48 | anything special if done as root). |