If you were Registered and logged in, you could reply and use other advanced thread options
|
Posted by Bob Smith on October 16, 2009, 4:26 pm
Hi
I would appreciate the opinions of the Linux robot builders
in this group. The question is whether you would prefer a real
device driver for robot peripherals or a unix socket interface
to it. Some background on my question can be found at:
http://www.linuxtoys.org/usd/UserSpaceDrivers.html
I am building a set of robot peripherals in an FPGA. The FPGA
card connects to a Linux host system over a USB-serial link.
I would like to offer device drivers for the peripherals on the
FPGA card and would like to use a user-space device driver.
My question is about how that daemon talks to the higher level
robot control applications.
One approach is to offer a set of unix sockets for each device.
For example, stepper motor controller might have unix sockets at
/tmp/board_0/slot_2/step_count // the step count
/tmp/board_0/slot_2/step_rate // steps per second
A high level application would have to use socket() and connect()
to open communication to the devices. To set the step_rate from
the command line would require something like
cat "1200" | socat - /tmp/board_0/slot_2/step_rate
The other approach is to install a small kernel module and create
a "real" device node for each peripheral. This is what is in the
article referenced above. The device nodes might appear as:
/dev/board_0/slot_2/step_count
/dev/board_0/slot_2/step_rate
A high level application would just use open() to establish
communication with the peripheral. To set the step rate from the
command line would require something like
cat "1200" > /dev/board_0/slot_2/step_rate
This approach requires compiling and installing two GPL'ed modules.
See the article for more info on the two small modules.
-- So, is having the convenience of a real device driver worth the
extra effort of compiling and installing a couple of modules?
--Or, is having to use socket(), connect(), and socat worthwhile
if it avoids having to deal with the kernel at all.
-- In a marketing sense is there much difference between:
"Full Linux support including all source code", and
"Complete Linux drivers including all source code"?
thanks
Bob Smith
|
|
Posted by Ray on October 17, 2009, 11:59 am
Bob Smith wrote:
> -- So, is having the convenience of a real device driver worth the
> extra effort of compiling and installing a couple of modules?
> --Or, is having to use socket(), connect(), and socat worthwhile
> if it avoids having to deal with the kernel at all.
For most purposes, I would vastly prefer a device with a
well-documented network interface and a userspace UI
client, rather than a device whose drivers run in kernel
space.
When stuff goes wrong with a communicating application in
user space, a typical user ("the code monkey") can debug
it. With the right interfaces (typically SSH) it can even
be done remotely. If stuff goes wrong in kernel space, it
requires someone with a much higher privilege level and
specialized knowledge ("the kernel guru") to debug. Also,
code running in kernel space has to be reviewed and vetted
by yet another specialized person ("the security wonk")
at most installations.
Finally, the kernel driver, if there's something wrong and
it has to be fixed, usually requires a reboot. Reboots
interrupt remote SSH sessions, and if for any reason it
doesn't come back up correctly, if you're not local there's
nothing you can do. So with a kernel-space driver you
don't dare debug anything remotely.
That said, there's a speed advantage in a kernel-space
driver and a cost disadvantage per piece in having a local
FPGA that handles network communications and local control.
But I think the advantages of a userspace UI client and
networked device are worth it.
Bear
|
|
Posted by bsmith on October 19, 2009, 10:26 pm
Ray wrote:
> For most purposes, I would vastly prefer a device with a
> well-documented network interface and a userspace UI
> client, rather than a device whose drivers run in kernel
> space.
OK. Sadly, we do not have time to wrie a userspace UI client right
now. We are, instead, trying to do a good job on the datasheets
for each peripheral. We may use unix sockets instead of TCP
sockets -- the namespace (the filesystem) is easier for unix
sockets versus TCP port numbers for which namespace collisions
are likely.
Before committing to unix sockets I would like to understand
John Nagle's comments.
> That said, there's a speed advantage in a kernel-space
> driver and a cost disadvantage per piece in having a local
> FPGA that handles network communications and local control.
> But I think the advantages of a userspace UI client and
> networked device are worth it.
We are putting time critical stuff into the FPGA: the pulse
width for a servo or the dead-time when switching direction on
an H-bridge controller. Really precise timing needs dedicated
hardware. Controlling that dedicated hardware is relatively
slow. That is, how often do you adjust the speed of the motor
or the angle of servo? Usually at most a couple of hundred
times a second.
The reason I mention the above is by way of saying that the
two trivial drivers (fanout.ko and proxy.ko) I am considering
are not for precisetiming, they are just one type of API. TCP
sockets or unixsockets could also be used.
Bear, thanks for your reply.
Bob Smith
|
|
Posted by John Nagle on October 19, 2009, 1:45 am
Bob Smith wrote:
> Hi
> I would appreciate the opinions of the Linux robot builders
> in this group. The question is whether you would prefer a real
> device driver for robot peripherals or a unix socket interface
> to it. Some background on my question can be found at:
> http://www.linuxtoys.org/usd/UserSpaceDrivers.html
Take a look at two open source projects already used for robot
control: The Willow Garage robot operating system
("http://www.willowgarage.com/pages/software" )
and "Player/Stage".
("http://playerstage.sourceforge.net/" )
Sending text over sockets, organized as if you were writing
to device registers, is not the way to go. You need a messaging
protocol.
Also, nobody uses stepping motors for mobile robots much any more.
They use full power under no load, and consume power when stopped. So
they're awful for battery life.
John Nagle
|
|
Posted by Frnak McKenney on October 19, 2009, 11:38 am
> Also, nobody uses stepping motors for mobile robots much any more.
> They use full power under no load, and consume power when stopped. So
> they're awful for battery life.
Sorry to jump in like this, but your comment piqued my curiosity.
A few years... okay, decades... back, it seemed like every robot
article I read talked about using stepper robots in homebrew
machines; "standard" DC motors were mentioned, but not nearly as
often.
Is my memory playing tricks on me? Or were there reasons why stepper
motors were more popular for hobbyist use a while back? I know that
they seemed more readily available from discard bins (floppy drives,
hard drives, printers), and a pulse-to-distance-moved calculation
might have seemed more "precise" for ded. reckoning purposes.
Frank McKenney
--
In medicine we all want certainty -- but we'd settle for rigor.
Rigor, though, demands a high price in the complexity and size
of experiments; and the numbers required for confidence in the
results may be beyond any institution's capacity to adminster.
Ultimately, we reach a point where society has to trust the
researchers to isolate the right variables in the right studies.
We will never be entirely free from medical tact.
-- "Chances Are..." / Michael and Ellen Kaplan
--
|
Page 1 of 3 1 2 3 > last >>
Related Posts
Latest Posts
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map