NEW 2009 Control System Released

[dcbrown]

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions

• . VxWorks is essentially (very!) unix-like operating system.

• it uses a BSP (board specific package) as h/w abstraction layer so it can be targetted to multiple platforms. The BSP exists for the cRIO. The normal VxWorks comes with a bunch of different BSPs, we may end up with a stripped down version of the environment with only the cRIO - that would make sense.
• there is a configuration process whereby you add in or remove components that you want in the RTOS build - standard stuff. Which means you can add rom-based file system, FTP, and other capability that is already available in the VxWorks kit as needed. There will be a standard config for competition, but for prototyping this opens up lots of stuff like application data logging during testing via WiFi. There are separate Broadcom device drivers available, for example, and other 3rd party driver packages.
• The IDE (Workbench) is Eclipse-based. You have the ability to add REAL breakpoints and other stuff for debugging. You'll need to compile with debug flags, otherwise you only get assembler view. Compiling w/debug goes for any libraries you'd use which is why any FIRST provided added-value such as pre-canned drivers for gyro, et.al. would need to be in a controlled source form.
• Both the Wind River C and GNU C compilers will work.
• VxWorks is RTOS, applications are either integrated into the kernel or as application. Multitasking native with 256 priorities and round-robin scheduling within priorities (so essentially unlimited tasking until you run out of main memory).
• a ton of documentation is available (I'm looking at 100mb of stuff), everything from getting started, to writing your own BSP (as if we'd ever need or want to do that!). For software mentors, start reading!
• (ok weird factoid), interrupt latency is slightly better than RTLinux, at around ~70usec (published number was 100us but that was on a MPC8260 @200Mhz processor vs 400Mhz MCP52xx of cRIO... but should give a ball park figure).
• fun stuff like a shell window on the target (cRIO) that you connect to and use from the development host [I guess like a console].
• lots and lots of other good stuff if you're an applications programmer.

Someone (WPI?) will provide the pre-canned "driver" software for the common interface devices; gyro, camera, sonar, and the like similar to the WPILIB today. It will be provided in source form. This combined with a default VxWorks project will provide the default/base code for the robot next year. I haven't read far enough into "Wind River General Purpose Platform, VxWorks Edition - Getting Started" to see how much work it will be to change drivers, but if the pre-canned driver software is open-sourced then you could use that to slightly modify things as needed for your robot - but suspect that shouldn't be needed often.

Custom h/w and/or driver software will likely be discouraged the first year. Both would make it difficult to provide the type of deep generic support needed across all the teams. The programming of the FPGA will be canned and shouldn't be touched by individual teams again for the same reasons. Maybe in later years we'll be able to change this.

LabVIEW is built on top of what VxWorks provides, so C/C++ is actually the native method of building apps.