Integrate Log and Logger into the main stream

[kyraha]

Description:

Matt has been working on logging functionality for the robot code. It is a lot more powerful way to diagnose how are the robot's components doing than to inject SmartDashboard outputs at random places all over the code. We definitely have to learn how to and start using this feature.

Requirements:

Link all robot's sensors to the Logger and make it collect data in the background. Educate the team how to send custom data to the logger from other places.

Acceptance criteria:

The logger shall work seamlessly in the background. The log file has to be easily accessible and readable for diagnostics and debugging.

[mattico]

I have some of the functions within the robot attached to the logger already, but I'm sure there are still some more. The main issue which is preventing it from being merged mainline, however, is that it currently crashes sometime after the robot is enabled. I'm still in the process of debugging it, but i'ts probably due to the way that class Sensor is implemented. The whole system could be implemented much more idiomatically if we had c++11 shared_ptr or lambdas or closures or Boost::shared_ptr or any number of modern features... cough cough

I know that both of those options are bad ideas for a number of reasons, but I just needed to get that off of my chest. If you have any thoughts about possible better methods of implementation, lets talk!

My goal right now is to document how the (admittedly fairly simple) works in the comments. And to fix the crash. Help.

[mattico]

Current implementation (not-finished) is planned to go as follows: Subsystem Logger Controls everything Command Log is the default command of Logger, and it continuously logs sensors which are always changing (like gyros, encoders) Template Class Sensor<T, T> encapsulates a Sensor input -- You give it a class pointer and a function pointer and it supplies a simple get method to access it.

Right now I'm updating all of the old-style add_sensor() calls to the new format, and also realizing that I'm going to need a separate vector to store Sensors which have different return types, unless I hide that again with a switch statement, etc. My original implementation didn't have templated return types, it just cast the function call to a double and returned that. I might just do that since it works for our specific case.