[General]
Check the logs! Very few things will fail without putting something in the logs.
  If they do, that is a bug unless our code is never getting run (there are
    innumerable ways that could happen, but it generally doesn't).
  To check the logs, run `LogDisplayer` if `BinaryLogReader` has been started or
    just run `LogStreamer` if you want to do simple testing without writing logs
    to a file. See `LogDisplayer --help` for options.
All of the binaries get put in the same place. That is
  src/out_atom/Default/outputs on the build machine and
  /home/driver/robot_code/bin on the fitpc.

[Startup]
Low level startup errors often end up in /aos_fatal_error.* on the cRIO and
  /tmp/aos_fatal_error.* under linux. Also helpful are the /tmp/starter*_std*
  files (if the standard start scripts are being used) and
  aos/crio/bin/netconsole.sh for reading cRIO stdout and stderr.
    If lots of the /tmp/starter_*std* files (with different numbers) are being
    created, that means that starter_exe is dying constantly.

[Anything Not Running]
Check starter_exe's log messages. They might mention that it is constantly dying
  on startup and being restarted.

[Control Loop(s) Not Working]
Are robot_state messages going out? An aos::JoystickInput (often JoystickReader)
  should be sending them.
Is it being fed goal messages?
Is it getting position messages?
Is something looking at the output and doing something useful with it?

[No Driver Station Packets]
Check to make sure that JSR (a cRIO-side task) is saying that it's sending
  messages. Also check JoystickReader (or whatever inherits from
  aos::JoystickInput) is running and see if it's receiving anything.

[Attaching a Debugger]
In order to make attaching a debugger very useful, you have to compile the code
  with debugging symbols. The way to do that is to modify the appropriate
  build.sh to pass "yes" instead of "no" as an argument to the aos build.sh. You
  have to modify a .gyp file (touching it is sufficient) to get it to use the
  new build flag.
Attaching GDB to an existing robot code process works like normal (you have to
  root first because that's what all of the code currently runs as).
If a process is dying repeatedly, the easiest way to debug it is to kill
  starter_loop.sh and (it has to be after that) starter_exe. After doing that,
  NOTHING will get restarted (including the normal restart after changing a
  binary) so that you can start a process under GDB like usual (shouldn't need
  anything special if done as root).