Beta testing the new 2009 control system for the FIRST Robotics Competition is turning out to be pretty interesting work. I'm meeting up with a mentor from a nearby team on Tuesday and Thursday evenings in addition to Saturday afternoons to crank through the key testing tasks. We got our test robot driving today, with full pneumatics and motor controls. Thursday's task will be getting the key sensors working for the teleoperated mode PID control loops, and then Saturday we'll start on programming autonomous operation.
The robot side of the platform is basically a slightly customized National Instruments cRIO, and has a ~400 MHz PowerPC and ~2M gate Xilinx FPGA (the latter is used for safety control, so we can't reprogram it). Programming the PowerPC can be done with either LabView or C++. Quite a step up power-wise from the old control system, which used a 8-bit PIC microcontroller running at 16 MHz (with 32K of RAM).
The operator interface (what goes in the driver station and interfaces with joysticks, etc for teleoperation) is actually an embedded Linux device (yes, I've telnetted to it). The good news is that it happily interfaces to all kinds of USB devices, something the old control system never really handled (it was gameport based). The bad news is it takes *forever* to boot up. Like 45 seconds. Compared to the instant-on of the old control system, this just drags. Boot times are also an issue with the cRIO.. 30-45 seconds there as well, compared with the instant-on of the old system. I continue to be amazed that as stuff gets faster, things like bootup times just get far slower. Are the autoprobing protocols so poorly designed they take *seconds* (billions of machine cycles) to recognize what/if a device is there? These platforms in particular are flash-based, so it's not like there's hard drive seek times, etc, either. I can't imagine any hardware I would design of having startup times of over a second.
The wireless connections are pretty sweet. Basically it's all TCP/IP over 802.11a/n. Eats up a ton of processing time on the robot, of course, but with a 400 MHz processor, it has time to spare when we're only updating our control loop every 40 ms or so. The best part of it is being able to have your laptop connect wirelessly to the robot network and download new software, reboot, etc, while the robot is 50 ft away.
Programming the thing in C++ is actually pretty enjoyable thanks to some great libraries developed at WPI (university). I've not drunk the LabView kool-aid yet; I've been programming non-graphically so long (over 20 years) that my brain just doesn't like to wrap itself around LabView. I suspect I'll get the hang of it eventually thanks to my hardware design experience (as LabView is sort of parallel that way) but I'm not sure I'll ever feel truly comfortable in it.
Anyway, it's fun, and I thought I'd share.
|comments: 2 comments or Leave a comment|