[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 `log_displayer` if `binary_log_writer` has been started
    or just run `log_streamer` if you want to do simple testing without writing
	logs to a file. See `log_displayer --help` for options.
All of the binaries get put in the same place. That is
  src/outputs/prime/outputs on the build machine and
  /home/driver/robot_code/bin on linux.

[Startup]
Low level startup errors often end up in
  /tmp/aos_fatal_error.* under linux. Also helpful are the /tmp/starter*_std*
  files (if the standard start scripts are being used).
    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
  joystick_reader) should be sending them.
  Also, kFakeJoysticks in aos/input/joystick_reader.cc has to be set to
    false in order for anything to get output.
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]
TODO(brians): This is out of date.
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]
Attaching GDB to an existing robot code process works like normal (you have to
  su 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).