Robots: sharing ideas

My robot runs Linux also. I wanted to spend more time writing robot software than fighting the operating system.

Several members of our club use mini-ITX boards, and I run something very similar.

The above items are also popular at our club. I think one member used an IR mouse/keyboard rig with similar success.

I use DC/DC converters (basically an encapsulated switcher). Some are up to

90% efficient.

I just plugged a PCI wireless card into the motherboard.

[snip]

I have used xawtv to display output of the robot's webcam on a notebook. The notebook is only 400MHz, so the X server is not fast enough to make the video very useful.

Jeff.

"mlw" wrote

I'm in the exact same spot as you, I'm starting the construction of a mobile robot and I'm researching what is going to be the "brain" of my computer. So far I had thought about serial wireless modems (maxstream), PDAs (compaq ipaq), tablet pcs (hp tc1000) and so on, but reading your post, it makes sense to use single board computers. I want the computing power of a desktop PC IN the rover, but with the size/weight of a microcontroller board with reasonable power consumption. tablet pcs provide that, but with lots of extra components (more weight, more power consumption) that are not necessary for the rover computations.

Well, I don't like linux. I think it's personal. It's more prejudice than technical. I don't know. But, if it proves MUCH MUCH better than windows, then I'll probably give it a shot.

Which one are you using? I saw this one on mouser catalog:

pentium M 1.4Ghz, 11x9cm, 0.8Kg, not bad hun?

I'm using an RC monster truck. I will test both electric and nitro powered.

I'm thinking about using battery packs that are used in RC cars (usually

7.2V), they are small, rechargeable, and they don't expect to be recharged while in use.

My goal is to have the robot completely autonomous, no interface at all (except emergency stop). But I may use a wireless network card to do online monitoring of the system and why not teleoperation?

I'm developing a PID controller for a DC motor right now (for school), and I want to avoid it for my rover, that's why I'm going to use an RC car, everything is already built in. If it is electric, I just have to send a 5V pwm signal to the electric drive. Same thing for the nitro version, pwm signal to the throttle control servo. (I'm working on suspension and gear reduction, this little things are velocity beasts!)

Why not doing the video processing in loco? See, this is the main reason why I'm avoiding wireless. If my robot had only low throughput sensors (encoders, gps, accelerometers, gyros, etc), then I'd go for the completely wireless solution, but because of the video stream (too much data to go wireless), then I'm leaning towards putting all the processing power in the rover.

Nice one! Congrats!

I'll start my robot-construction blog very soon, I'll post it here when I do it.

Cheers

It just makes sense to use a small PC motherboard, the mini-ITX jobs are great.

I have a lot of experience with both Linux and Windows. I actually published a couple articles on Windows programming, including 95/NT device drivers.

I can tell you from a technical perspective, if you want to do something cool with your robot, you'll want to use an open source unix. Windows is just a royal PITA to do this sort of thing on.

For instance, on unix, I can write application code that talks directly to hardware. It has to be market with special permissions, but it can be done. You can't in NT (XP).

Besides, all the tools, the OS, everything is free. Anyway, I would strongly recommend Linux.

I'm using an EPIA something right now, it is a year old and slower.

All the math says that NiMH batteries have the highest power desity. A small AA NiMH battery can have 2.3 AH (2300 mAH), that is simply amazing. If you can get your power requirements low enough, you should be able to use a few NiMH batteries.

I'm using sealed gel lead-acid batteries, I can get them cheap and my robot is pretty big.

There are times when I direct interface is helpful. Every now and then, computers don't like to talk on the network, and you'll need a keyboard. That's why data centers have crash carts.

Are you using "stepper" type motors where you sent pulses to move specific amounts or a servo system that PWM?

I've never heard of it.

811G has great bandwidth.

Well, yes all the processing is on my robot. The point is it is cool to get telemetry from the beast.

811G has pretty good bandwidth, and an mpeg encoded image with video camera resolution is pretty manageable.

You have a good start. How far along are you with software? I spent months putting my hardware together, using spare evening hours. I have spent 10 times that on the software. Hardware is easy to do, it acts a certain way according to datasheets. Instructions, diagrams, etc are available. There are no unknowns.

When you start making your software, that is where it gets fun and interesting. There are no datasheets, diagrams, etc on your brain. How do you transform something we take for granted (walking around a house we've never been in) into computer logic?

You have to dissect the problem into tiny bits to be able to code it.

R

Ain't it the truth!

I didn't like I/R because of the whole line-of-sight issue, but they have better range than R/F (if aimed :-)

Yea, my switching power supplies are DC/DC converters, they are same thing.

Yea, that is nice, but I'm actually curious about using a Linksys wireless router with one of the Linux ROMS. I'm wondering if I can put some network interfacing in the router as well as a dead-man alert. If the router detects that the computer is no longer reponding, maybe it can do something.

There are a number of packages that will transmit a digital video stream. If your system is fast enough, it may even use mpeg compression. (A REALLY good camera may already provide an mpeg stream.) That will reduce your bandwidth.

At the "LOWEST" level, rip apart xawtv, lop off the display and take the reader part of it and send it out on a socket. Take the display part and read the socket as if it were the video.

snipped-for-privacy@gmail.com wrote: [...]

That is called Good Old Fashioned Artificial Intelligence or GOFAI for short.

It is probably not how real organsims work as it always remains programmer dependent for finding bugs and devising improvements to enable better ways of performing the tasks.

To be honest, my first "real" job in technology was at Denning Mobile Robotics back in the early '80s.

Software can be hard, but so too can be hardware. Often times I have the idea in my head but lack the tools to create them. (Don't get me wrong, I have a fair set of tools ranging from a drill press to a 4 trace asciloscope)

Electronics, maybe. Robot hardware has some mechanical qualities. Motor torque, speed, stresses, acceleration, etc are all touchy feely sorts of things.

Until your battery drops to 11.5 volts and things start getting flaky, or your PWM amplifier is dropping spikes on your power causing your computer to shut down.

I've done most of the elements of the software before. I've done some vision systems, motor control, and stuff like that. I've even programmed mobile robots before (early '80s). There are some aspects that I am excited about and I want to get my platform built so I can work on the fun things.

"JGCASEY" wrote

That's not completely true, behavioral robotics also works like this. You dissect the problem in little reactive modules that are independent of each other. The sum of all these small "behaviors" make the final desired behavior "emerge".

A side track:

How is behavioral robotics nowadays? There was a lot of stuff about it in the late 90s. People like R Brooks, P. Arkin were doing a lot.

What's happening now besides Kismet? Or is Kismet not behavioral?

But it seems that it's more or less died down now.

Looking at SLAM, a lot of work (if not all) is on probabilistic models (generative).

Is behavioral passe?

Padu wrote:

Well, that's not entirely true: there is a way to give user-level processes access to I/O registers. It requires a small kernel-mode component, but it doesn't mean you have to write it. Many off the selve solutions are available, I personally prefer the winio

one. That can even give you access to the physical memory address space if you need that for some reason.

Regards, Andras Tantos

Hi!

I'm doing the same thing (modifying an RC car platform to become a robot) but I've found that a PID loop is essential. The speed-controllers for these cars are not much more than an H-bridge. You will be running at the lower end of the RPM range of the motors even if you gear them down, where open-loop control will perform miserably. I ended up developing my own H-bridge with local intelligence for the PID loop. If you're interested, take a look at here:

(and some Wiki-like info on the hows and whys here: Regards, Andras Tantos

In scanning for mini-itx I found this smaller mobo:

Is this too new to use (know zilch about this ...)? Seems pretty cool.

mlw wrote: [...]

What do you call fun things?

What kind of vision systems have you done?

Vision systems have interested me for some years but I have found very little desire from others in "sharing ideas". Of course it is possible they have no ideas to share :)

The thing about robots is that there are really three skills required if you start from nothing. Mechanics, electronics and programming.

Due to time limitations I have made the choice to stick to the programming side and buy the hardware where possible.

Because we all use different hardware/OS configurations sharing without needing to completely re write the software is difficult.

John Casey

Well, I know of a lot of ways around WinNT's various "protections," I was overly broad -- obviously. One of my favorite kernel calls is ObReferenceObjectByHandle, it allows a user space application to share interesting things like event handles to be used in the kernel. Once in the kernel, one can do *anything*.

The problem is that most of what you *can* do is usually an artifact of poor design decisions or obscurly documented and mostly circulates by word of mouth or 3rd party web sites like sysinternals. With Linux, or one of the BSDs, you have the source and you see how it all works. No secrets.

I'm using a slightly older VIA EPIA mini-ITX board, its small, but not that small, maybe a centimetre or so bigger. :)

AI and navigation. Phased ultrasonic sensors. Stereo vision.

Just simple defect in a fairly constant background system.

lol. I've seen that as well. Even the books on the subject seem to dodge any real substance.

Very true.

I HATE buying overly expensive hardware. I started out as a hardware technician, then engineer, then software. So, I can do both. I was also a shop troll in high school, so I have a feel for the mechanics as well.

I really can't imagine how difficult my robot would be on Windows. I've done a fair number of NT device drivers and while the environment is nice for simple things, any project that requires a reliable interrupt rate is screwed.

That's not true. There's a wealth of info (books, papers) on computer vision in general. There's lots of stuff on SLAM as well.

"mlw" wrote

Why would I want direct access to hardware on the PC side? To make things more modular, I'm creating a message architecture that sends out all the information gathered on the rover through a serial link (using microcontrollers), the only exception would be the camera system, that would be linked directly to the PC, but for that there are some directX libraries to access a video device without much layers.

I want to be able to easily change "brains". If the only coupling point between the rover and the brain is a serial connection over a well defined software protocol, then it doesn't matter if the brain is windows, linux, a PDA or even if the brain is miles away, connected through some sort of wireless modem. Or is that an utopia?

Got any reference code? Most of of the stuff I've read is conceptual, and I do enjoy coputer science theory a lot, it can get pretty dry pretty fast without some meaningful stuff to look at.

SLAM?