Linux router as embedded computer for robots

Posted by Eddy Wright on January 24, 2010, 12:20 pm

> My general feeling is that a real-time Linux variant plus a bunch
> of $1 MCU's can provide a very flexible and cost effective control
> platform for robotics.
> -Wayne

That sums it up pretty well :-)

Eddy

Posted by John Nagle on January 19, 2010, 3:06 am

Joe Pfeiffer wrote:

>> Joe Pfeiffer wrote:

> I can't imagine trying to close a servo loop with a processor running a
> "real" OS (Linux, XP, or anything else worthy of the name), no matter
> what hardware was doing the details of control and sensing. Things like
> that are what $1 specialized MCUs are for.

It depends on how complex your servo control is. The Big Dog robot
closes its position and force servo loops at 1Khz, and the balance
and locomotion servo loops at 200Hz. All that runs on a ruggedized
Pentium-based PC/104 machine, running QNX.

The LIDAR tilt head on the CMU Grand Challenge vehicle closed its
servo loop at 1KHz. Again, this was running on QNX.

If you're just doing simple PID position control, some little MCU can
do the job. But if you're doing adaptive feedforward control or coordinating
multiple flexible actuators, you need more than that. Modern robot control
systems are using machine learning. This stuff is compute and memory intensive.

John Nagle

Posted by BobH on January 19, 2010, 1:03 pm

Joe Pfeiffer wrote:

>> Joe Pfeiffer wrote:

>>> A *lot* more, and you've still got the sensor problem. That parallel
>>> USB adapter still seems a better bet....

>> I have used the FTDI chips and associated driver to do parallel
>> I/O. The latency for USB scheduling and transmission means that 1mS is
>> as fast as it could get and around 3mS is what I have observed. The
>> platform that I was running under was windows xp, but I doubt that
>> makes a lot of difference in the scheduling latency. 480 mBit/second
>> USB II still only ships a frame per millisecond. This much latency
>> would be fine for whisker sensors, but you could not close a servo
>> loop for motion control with it.
>> I have messed with the Microtic router boards. They have a compact PCI
>> board interface for up to 3 boards. That seems like the path for I/O
>> to me.

>
> I can't imagine trying to close a servo loop with a processor running a
> "real" OS (Linux, XP, or anything else worthy of the name), no matter
> what hardware was doing the details of control and sensing. Things like
> that are what $1 specialized MCUs are for.

Joe, I wasn't commenting on the sanity of using a standard OS for
running a servo loop. I agree completely with your comment on that. I
was commenting on the long and variable latency that I/O done over USB
gets. Measurement data in + control data out could not happen in less
than 2 mS, even with no scheduling or calculation latency.

There are certainly plenty of things that this would not be a problem
for, but it is a limitation.

Regards,
BobH

Posted by Eddy Wright on January 24, 2010, 12:19 pm

Hello Everyone,

Modern computers use dedicated processors for subsystems such as video
and sound, would seem to make sense to follow this pattern for I/O
intensive functions too. Using USB for the interface isn't as clean as
having it embedded but it would work pretty well if the MCU handling I/
O is programmed to be self-sufficient as much as possible. Think of
the I/O MCU as your robots autonomic nervous system, monitoring
sensors and controlling motors, while the netbook is your robot's
brain. Instead of the MCU sending a message to the brain that there
are steps right in front of us and wait for the brain to stop, the MCU
knows that steps are bad, stops the robot and sends a status update to
the brain saying we stopped because of the stairs.

I'm sure that a lot of lower level I/O functions could be done by the
brain, but does it make sense to do that?

Eddy Wright
Wright Hobbies Robotics
http://www.wrighthobbies.net

Posted by gidesa on January 25, 2010, 8:38 am

> Modern computers use dedicated processors for subsystems such as video
> and sound, would seem to make sense to follow this pattern for I/O
> intensive functions too. Using USB for the interface isn't as clean as
> having it embedded but it would work pretty well if the MCU handling I/
> O is programmed to be self-sufficient as much as possible. Think of
> the I/O MCU as your robots autonomic nervous system, monitoring
> sensors and controlling motors, while the netbook is your robot's
> brain. Instead of the MCU sending a message to the brain that there
> are steps right in front of us and wait for the brain to stop, the MCU
> knows that steps are bad, stops the robot and sends a status update to
> the brain saying we stopped because of the stairs.

I agree with you. The netbook-nettop or similar is the base platform
for more "abstract" intelligent computing, or heavy task as computer
vision.
MCU can optimally do the sensor interaction, or base task as could be
PWM on motors, servo loop, etc.
And today there are cheap microcontrollers that are really "beasts",
indeed they could do also some type of computer vision computing.
The great advantage of standard architecture pc, as netbooks, is that
they can use a bunch of very cheap peripherals: webcam, bluetooth or
wifi devices, memories, and so on. Connecting similar peripherals
directly to a microcontroller is not so easy, and not so cheap.

Page 4 of 5 < 1 2 3 > last >>

Subject
Posted In
Date

is this a good chouce of real time linux ???
General Robotics Forum
2005-09-16

small robot for playing with computer vision algorithms
General Robotics Forum
2011-08-10

New open source framework for computer vision
General Robotics Forum
2010-08-06

VisRecog module of MindForth AI for robots
General Robotics Forum
2011-09-23