fixed curly braces.
initial commit of the PVT code.

I think this stuff might work. it does compile, so that's good!
this is untested on the robot so far. more needs to be written
before that can happen.
handle the control word and mode selection correctly.

this flips the bit that makes the pvt mode actually go as well as
setting the right mode when you add a pvt segment. I've also included
a startPvtMove and a stopPvtMove method. the intended use is to
add at least two pvt segments, then call startPvtMove. to stop
you can either add segments that stop, call stopPvtMove and specify
a duration to reach zero velocity, or call stopPvtMove and set the
optional emergency bool to true which immediately flips the control
word bit that stops the servo.
oops, fixed dumb compile error.

should have totally attempted to compile before committing!
turn on c++0x for platform_motion

mostly so I can use for(auto x : vector). it is awesome.
added wheel diameter to the wheelpod constructor.

updated motion.cpp to pass it in correctly. wheel diameter is
super handy because it allows the wheel pod code to deal with
real units all the way through. the previous units for wheel speed
were in revolutions per second.
added position and time code to the WheelPod class.

this lets you specify a series of segments that define steering
angle, steering speed, wheel distance and wheel speed in actual units.
the wheel pod code then converts those units in to servo-friendly
units and passes them on to the PVT code I recently added.

note that there's a hard limit on how long segments for the servo
can be: 255 milliseconds. If you pass a segment in that exceeds
that duration, the wheel pod code will attempt to break it up into
smaller segments, but the way it does so may cause problems.
it is probably better to assume responsibility for the segment
length and keep the segments short enough to not hit this bit of code.
added a more data needed callback to the CopleyServo class

now when the buffer is running low on data (fewer than 3 items there),
it will fire a callback that asks for more. this is to let you run the
buffer as empty as possible to enhance reaction time.
plumb the more data callbacks through the wheelpods.
watch the buffer depth on the servos.

when we've added enough data to push the buffer beyond lenth 2,
tell the servos to start moving. it is unclear if you need to do this
after an underflow, but you definitely need to do this the first
time you start moving. hopefully doing this automatically isn't a
terrible plan.
stubbed out system to send data to the wheelpods as they need it

there are still things that need to get implemented here.
added a planned path callback.

now we should be able to handle planned path messages, in theory.
the remaining missiong part here is the interpolation code and the
velocity planner required to turn planned paths into actual pvt segments
for the servos. once I have those things, this whole system will be
ready to test. scary!
added missing include.
added scary servo test. only use this on the wheels!

if you try to use this on the steering, bad things will happen!
fixed a bug in PDO sending.

now when you send a vector of bytes that's less than 8 bytes long,
it won't send a bunch of garbage at the end of the PDO.
bug fixes to teh CopleyServo class

the most important being initialized variables and switching the pvt
pdo to immediate mode instead of commit on sync. it turns out that
the servos don't like getting a ton of pvt pdo messages that commit
on sync between sync packets. oops.
now the horrifyingly hard coded pvt test works!

make totally sure you never run this on the steering, that would
be bad.
fixed some comments.

no really, nothing to see here, I swear!
added a move method that only takes a single segment.

turned the multi segment method into a helper function. this is
more in line with the current plan for how we'll actually use this
stuff.
now the platform motion code will tell the robot to stop when there's no
path

this is probably a good thing, but might actually conflict with other
control modes. I'm going to have to think about that...