Let's have Linux Robots Next Year!

[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

[Adam Y.]

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

It would probably be cheaper/lighter/more durable if you look at this www.gumstix.com

[jdong]

Hmm, Xscale chips... Same basic idea. It's just that I venture to say 90% of teams have some old laptop lying around without a purpose....

I personally prefer to work off an x86 based chip, because of my familiarity with them!

[jdong]

Correcting an inaccuracy in the original description: The Dashboard port is a 1-way interface. It can NOT be used (as it's currently set up) to send new data to the robot.

[jdong]

I've investigated a bit of kernel latency testing on my desktop, and have came to a conclusion:

26.2ms is an extremely slow loop. There's no problem with running any kind of code in this timeframe!

[jgannon]

Originally Posted by jdong

Correcting an inaccuracy in the original description: The Dashboard port is a 1-way interface. It can NOT be used (as it's currently set up) to send new data to the robot.

I am intrigued by this project. However, keep in mind one thing:

<R69> All equipment connected to the Joystick Ports of the Operator Interface must be powered solely through the power available through the port. External power sources of any type are not permitted on any equipment connected to the Joystick Ports. Portable computing devices may not be connected to Joystick input ports on the Operator Interface.

As you've pointed out, the Dashboard port is one-directional, so the only way to send data to the RC is through the joystick ports. I don't know how this impacts your plan. Nonetheless, good luck, and keep us updated.

(On a side note, those gumstix computing devices look awesome... definitely something I'll keep in mind for future projects.)

[jdong]

Well, laptops are self-powered. They may only last a short time, but much longer than 2 minutes!

[jdiwnab]

Originally Posted by jdong

Well, laptops are self-powered. They may only last a short time, but much longer than 2 minutes!

But they have their own batter (aka an outside power source). Now if you could have the computer powered by the controller...

[Tom Bottiglieri]

Can you find a laptop from a COTS supplier for less than $200?

One that is powered by the on site power source??

I thought about the same thing earlier this year. We were going to communicate to the RC via the ttl serial port and run linux on an old laptop to run some of the more complex parts of our code, but soon found it was illegal.

[Venkatesh]

Lets ignore the rules/rulings concerning intelligent dashboard-connected devices for a second.

We can use the dashboard port as the output from the IFI stack to the laptop. And we can use the digital inputs of the Operator Interface as the inputs from the laptop to the IFI stack. The parallel port on a laptop would be well-suited to that.

Now what do you gain? A high-latency link to all robot operations and the flexibility to do whatever you want with them with the full power of a PC.

For many common tasks on the robots, this approach is unnecessary and doesn't add any advantages. As an example, suppose certain sensor inputs directly influence some motors. To have the sensor data flow all the way up to a PC and back down would be pointless when local operations could have taken care of the task.

Before this year, I would have said there was very little incentive to stack a PC on to this system. The only tasks that the PIC can't do natively are floating-point math, and you can purchase a PAK-II or III coprocessor to do that far more easily than you can have a PC do it (in the off chance that you absolutely need very accurate floating-point math).

The CMUcam changes this. If we could read the raw data coming from the camera (as opposed to processed data), we could feed it to a computer for analysis and processing and whatnot. It is very difficult to outfit a PIC (even an 18f) for analyzing a video stream in near-realtime. If a PC could be used, sudden magic possibilites open up. We could have robots analyze the entire field in autonomous mode and react to different field conditions. The variable-position tetras this year would just be a small step. Imagine autonomous mode with variable starting locations and robot interaction. Other than the CMUcam, new and powerful sensors could appear. Robots might sport miniature radar/sonar/ranging tools, to create a view of the field.

If you are very interested and have experience with esoteric electronics, there is an option. Get a book called "Troubleshooting IBM PCs". It is an old blue book, from the early 1980s. Included are the complete circuit schematics of the IBM PC, XT, and PCjr, CGA and MDA video boards, and printer control systems. You can try playing with an 8086 or 8088 CPU and linking it to the IFI controller. Then, you can add the 8087 coprocessor. Such a setup would allow you to use 16-bit PC C compilers and linkers to generate code. But a warning - it will be exceptionally difficult and yield little more than some cool demos.

Things like this will be seen in the future. Right now, however, they would be too hard to implement, for many reasons, some technical, some logisitic.

The idea of using linux to assist robot control is definately not a bad one. Gaining access to the full firepower of an x86-platform would give electronics and programming teams a field day and an acute migrate at the same time.

And good luck!

[AIBob]

The current processor now has a lot of the system calls for linux (well some), there is no real advantage to having another operating system on the chip, it would consume too much space even with specially stripped down OS code.
Loading linux onto the robots would make the code even more of a mess.
*Just add functions of the things that are on linux and share them with the rest of FIRST, some other functions would not be too bad.

[jdong]

I think you're not understanding: We're hooking up another COMPUTER to the controller via the serial port, NOT loading Linux onto a PIC18F -- I agree that's a hopeless attempt!


As far as advantages, I'm most interested in using real C/C++. I still cannot live with Microchip C, losing pieces of results while multiplying longs, and FP math is well desired for PID constants. I was considering a touchpad-driven robot navigation system also, which is impractical on the given micro.


I realize it's against the rules right now; I was asking that if anyone on the magical committee is listening, please consider allowing this setup next year!


It's not difficult either to transform a breaker panel output to a laptop-compatible voltage, if no "external power sources" are allowed.


P.S.:
Venkatesh: I've had a number of issues with the micro already this year, implementing closed-loop PID control on a few separate motors -- everything from garbled RAM to unfinished calculations.

[whakojacko]

nice idea, but im not sure how practical it would be with the current system. First/ifi would have to change a good amount of stuff to get it to work. Would be cool if it could happen though

[Venkatesh]

I am willing to bet that at some point, FIRST will move the PC-based controllers. It will not be soon. But the trend towards electronics/programming challenges is unmistakeable. The appearance of autonomous, extremely powerful custom circuits, current sensors, encoders, the PIC, C, interrupts, and the CMUcam, all in 3 years. Control has had a busy few years and will continue to do so.

When FIRST introduced autonomous in 2003, but stuck with the Basic controller, they created the "Year of the Kludge." All sorts of interesting systems came together - processor interfacing, tons of sensors, etc. When FIRST comes up with a new superdemanding challenge and the kludges come out of the closet, they will have an incentive to move to PCs.

I'd bet on a PC/104 system, with an InnovationFirst Powersupply, auxiliary chips, and default code. Maybe 2010? Maybe 2015? Who knows.

Whatever it is, its coming.

[devicenull]

I'd love to see it opened up to in the rules. I think that would be all thats needed before you started seeing them more and more.. I mean, I can think of a couple of cool things to do right away:
Display what breakers popped over the match.
Record data from the sensors for an entire match.
Different cameras would probably allow better vision stuff

It would be very nice to have more power then the current system, and access to more tools