copied everything over from 2012 and removed all of the actual robot code except the drivetrain stuff
git-svn-id: https://robotics.mvla.net/svn/frc971/2013/trunk/src@4078 f308d9b7-e957-4cde-b6ac-9a88185e7312
diff --git a/aos/common/debugging-tips.txt b/aos/common/debugging-tips.txt
new file mode 100644
index 0000000..5d52af2
--- /dev/null
+++ b/aos/common/debugging-tips.txt
@@ -0,0 +1,48 @@
+[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).