[jdong]

I'd like to give a possibility for the nerdy/daring teams: A Linux-powered robot!

This year, FIRST introduced the whole idea of "Easy Programming". Though great strides, like integrated PID and navigation scripting, were made, I still think overall we as a FIRST community failed to provide easy programming capabilities.

I've began to look into the feasibility of having a Linux system control the robot through the IFI standard Robot controller, via RS-232. Currently, it looks quite promising. Kernel-land control would work effortlessly, and I'm still seeing if user-land control can respond in time. This approach has a number of advantages over just the IFI Controller:

1. "REAL" programming language: You get full access to a standards-compliant, well-equipt programming language, not the watered-down buggy C implementation that we currently have. (No offense to Microchip, of course, we respect your efforts to produce a quality controller, acknowledge the great improvement that's always being made to MCC18, and certainly are gracious for your generous donations to FIRST). At the very least, you'll be able to use C/C++ (yeah, gcc/g++), and hopefully, you can use ultra-high-level languages, such as Python, Java, or Mono (.NET/C#).

2. Multiprocessing flexibility: Hopefully it'll accomodate multiple processes generating the data to output to the controller... That way, programmers can choose any algorithm they wish -- including lengthy loops (as long as the result comes out in time). The modular design allows teams to distribute binary components to others, allowing you to mix-and-match programs. Imagine how easy that'll be!

3. Open-source, Free-to-all programming: You can program on a Free, Open Source OS (Linux, etc), with a wide array of IDE's and tools.

4. It's cool -- Come on, who doesn't like Linux on robots?

A rough design:
In the 26.2 ms loop, the IFI RC's Default_Routine() will send a packet of all the Digitial ins, Analog in's, Joystick vals, etc to the serial port (Program or other one, who cares?)

The Linux control system will respond with packet(s) containing desired outputs.

The IFI


I've been looking through the 2005 rule book for any possible "loopholes" allowing this setup:

R54: Doesn't say you can't use other devices to "assist" the robot in calculation. Numerous allowed parts -- shaft encoders, gyros, etc do certain amounts of on-board communication.

There are clear rules against other devices outputting PWMs or other signals, etc. The Linux controller certainly won't do any of this ; all communication is done through serial, making it safe. Also, there's no methods of circumventing competition control, since the Default_Routine() and Autonomous_Routine() aren't called if you're robot is disabled.

There are virtually no rules on what's allowed at the driver's station -- Laptops are permitted. Communicating through dashboard on the OI would work, too!

This setup is inexpensive -- we're talking about a 200MHz laptop off e-bay, which usually is < $100. The software (Linux) is free.

As far as an "unfair advantage", I'll be perfectly willing to work with the community (and FIRST, IFI, etc), to document and provide example code and modules (Free and open-source, of course!).

Please, consider allowing this setup for next year! In the real world, straight microprocessor programming is being quickly phased out by autocoders (i.e. Simulink's RealTime Workshop). Embedded Linux is the future in control systems, and FIRST teams should have hands-on experience with this technology.


---
John Dong,
Team 245 Programmer and Misc. Electronics God

Ubuntu Linux, Forum Supermoderator
Ubuntu Backports Project, Leader & Coordinator
NYLF/TECH: Linux Security Lab, 2004 Staff