Controlling Robots with Linux?

propain asks: "I've recently heard of a few robots controlled with Pentium processors run by the Linux kernel. I would love to build a robot with Linux-for-brains and write my control code in C. What are the various challenges one must undertake in receiving input from various sensors and sending certain electrical voltage and current pulses to actuators and other output devices? I assume the answer lies in device driver programming and embedded Linux systems?" Anyone have pointers to webpages with useful information on this subject?

linuxdoc.org

[FLaMeBoY]

Check out the linux documentation project. There are several faqs which have basics on this sort of a thing. The Coffee faq is good amongst a few others. Have fun =)

this used windows, but...

[toast0]

http://quickwired.com/kallahar/robots_ghettobot.ph p

(previously on the front page)

they hacked together their own io card and some sort of driver

Distributed sensor/actuator control

[roystgnr]

Are you sure you need a Linux kernel controlling every tiny change of every low level actuator in your robot? Probably not. In general, you need Linux because of it's available software tools (being able to ssh to your robot, run gdb on your control software, etc. is nice) and because of the relatively heavy CPU power you can run it on.

For those sensors and actuators, you may want more low level control. You can get a 25Mhz PIC for $5-10, for example, and compile C code (a few kilobytes of it, anyway, with 8 and 16 bit integer arithmetic) to control a dozen A/D and D/A channels with latency in the hundreds of microseconds. You basically use the microcontrollers running your raw code (no OS) to handle closed-loop control of individual subsystems, then have them controlled in turn (by serial, I2C, or something else you can hook up to a PC easily) by a microprocessor running Linux.

And you might be surprised in the end. Our robot [rice.edu] was originally intended to work as above... but when time pressures hit, we discovered that our requirements for the master controller weren't as great as we estimated, and we managed to get away with using a PIC for that too.

The PIC isn't the only microprocessor out there... and it's got lots of limitations. The program memory is frighteningly small, the arithmetic precision is lousy, we had to try about three compilers before we found one that worked to our satisfaction... but it worked fine in the end. A piece of advice: even more important than these worries about your original design is *getting it prototyped early* and working out all the bugs. Our robot, for example, kept failing because a few damn interconnection wires kept coming loose... Some friends of mine never got much in the way of working hardware because they just didn't realize that this was a multi-thousand man-hour project, and didn't have enough available time budgeted.

Re:Distributed sensor/actuator control

[Bryan Andersen]

These comments are spot on. I'm also using small MCU devices for anything that needs hard real time CPU responce. That is motor control, touch sensors, etc. They are cheep and you can easily dedicate them to the task. You can use RS-232 links and have a serial port for each, or you can use RS-485 and use common links. I have two RS-485 links. One for the motors and the other is for touch sensors and slow update devices like compases. I also have a RS-232 set aside for GPS in the future. My central processor is currently only a 486 with Linux loaded. Rather slow, but it's fast enough. I have plans to replace it with something really fast so I can start to do vision work. But that won't happen for awhile. Standard PC hardware isn't quite fast enough yet.

With the PIC CPUs, you can get cheep C compilers. The C2C compiler is horrible, but if you combine it with GCC's C preprocessor it can be made passable, but just barely. The guy who wrote it needs to get himself a copy of K&R and really read and follow it. I do all my development under Linux and download code to the PIC using the PICSTART programmer. With another program (picp) I can use the PICSTART programmer under Linux. This allows me to do all my development under Linux.

For you host processor and motherboard you can go cheep and use and old PC, but then you have to have a huge robot. Otherwise there are many PC compatible single board computers out there. You can even find then surplus. Buying new you should be able to stay under $500 easily and still get a pentium class CPU. The main thing when selecting a board ig getting enough memory. You want atleast 16MBytes due to some of the current install scripts with the available distributions. I only have 8MBytes on my robot [nerdvest.com], but I loaded linux by putting the HD in another system and only copying the parts I wanted.

Try this site...

[biohazard99]

This site [geocities.com] has details about the MOLTAR project affiliated with the University of Kentucky LUG [uky.edu]. The jist of it is a GI joe motorized tank with a web cam for demo's and drawing ooh's and aah's from the crowd.

For once, I can answer in a somewhat informed way

[randombit]

I work at at lab at my university that does just this. It's called CIRL [jhu.edu], and sent a team to the recent Robocup competition (we lost).

One of the best parts of using Linux for robot control is you can do some fairly heavy processing on it (for example, put a Firewire DV camera on it, send the output to a firewire card, decode it, run various computer vision algorithms on the input, and decide what to do next).

However, for the lower-level interaction, we mostly use drivers provided by the people who did the robots for us (we're not really a robotics lab, more of a lab that does computer vision, and we test things out on robots). They provide the sources, of course, but it's not free (OTOH, I wouldn't want to have to write the drivers myself, soooo...)

If you are planning on building one yourself (a reasonable idea considering how much the ones we bought cost), I would strongly suggest you consider using some sort of 8 or 16 bit embedded microprocessor or something even smaller, for doing the actual control (another post had some details about this sort of thing). If you're really feeling 31337, wire it all up with just plain transistors (probably make it a real mess and hard to fix if something breaks, though).

Linux is useful enough on a robot, but it's not really a low level controller; you need something to centralize the control of the phyiscal components into one place, so your "real" computer can talk to just that single spot, instaead of some weird scheme where you would have wires running all over the place connecting directly to your computer somehow.

BTW, Wireless LAN cards in robots kick ass. :)

Also, I'm not sure how expensive it is, but look into ARCnet. It's an "embedded networking" sort of thing; some of the robots use it to connect together various parts (radars, cameras, the wheels, etc) and Linux supports it to some extent.