Linux drivers for robots: /dev or sockets ?
Bob Smith
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
Ray
> -- 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
John Nagle
> 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
Frnak McKenney
> 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
--
waynegramlich
> 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/")
Has anybody sucessfully downloaded ROS yet? I tried and their
configuration script was littered with bugs.
> Sending text over sockets, organized as if you were writing
> to device registers, is not the way to go. You need a messaging
> protocol.
Agreed.
> 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.
Most hobbyist robots use DC gear motors these days for the
reasons that John enumerates. In addition, stepper motors
lose torque at higher speed. On a flat surface, you can turn
off power to stepping motor and it will hold position, but
the power off retention torque is quite small and easily
overcome. While I occasionally see a hobby robot with a stepper
motor on the inside, it is definitely the exception, not the
rule.
-Wayne
BobH
> On Sun, 18 Oct 2009 22:45:09 -0700, John Nagle <na...@animats.com> wrote:
>> 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.
Another factor is that there are a number of microcontrollers available
now with quadrature counters and PWM generators onboard. These make it
easy to do closed loop DC motor drive. In the old days, quadrature
counting had to be done in software or external hardware. Also,
quadrature encoders with good resolution are available pretty cheaply now.
BobH
bsmith
> 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
bsmith
> 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/")
Thanks. Looks like Willow uses Player. Doing Player drivers may
make sense when we have more time. For now, we are trying to get
the low level stuff working and visible to a Linux program.
> Sending text over sockets, organized as if you were writing
> to device registers, is not the way to go. You need a messaging
> protocol.
OK. Shoot, text over unix sockets is the front-runner right now.
Why is text to a socket wrong?
Why is a messaging protocol better?
In the FPGA are a set of nine different, user selected peripherals.
Each peripheral has a set of registers that control its operation.
For example, the H-bridge controller has a register to control the
frequency of the PWM signal as well as the pulse width. The actual
protocol to the FPGA is a SLIP encapsulated steam of command and
response packets. Is this the kind of messaging protocol that you
would like to see? We are planning on documenting the register
sets and protocol, so maybe that's all that's needed?
thanks
Bob Smith
dhyl...@gmail.com
> > Sending text over sockets, organized as if you were writing
> > to device registers, is not the way to go. You need a messaging
> > protocol.
>
> OK. Shoot, text over unix sockets is the front-runner right now.
>
> Why is text to a socket wrong?
> Why is a messaging protocol better?
Messages usually have things like CRCs. That way you have some
assurance that the data wasn't corrupted along the way.
> In the FPGA are a set of nine different, user selected peripherals.
> Each peripheral has a set of registers that control its operation.
> For example, the H-bridge controller has a register to control the
> frequency of the PWM signal as well as the pulse width. The actual
> protocol to the FPGA is a SLIP encapsulated steam of command and
> response packets. Is this the kind of messaging protocol that you
> would like to see? We are planning on documenting the register
> sets and protocol, so maybe that's all that's needed?
Yeah. I would definitely prefer that level of interface. That way I
can do something more fancy if I like, but I can also be low-level if
I like. Then if you want to get fancy, provide a library which
translates a function API into packets, and a way of integrating the
delivery of said packets. Lots of programmers (especially beginners)
aren't as comfortable dealing with packet based protocols. But all
programmers work with a C API (aka the C runtime library).
By splitting (factoring) the code this way, you can move the "function-
API to packets" to any processor/micro quite easily.
Dave Hylands
Joe Pfeiffer
>
>> > � �Sending text over sockets, organized as if you were writing
>> > to device registers, is not the way to go. �You need a messaging
>> > protocol.
>>
>> OK. �Shoot, text over unix sockets is the front-runner right now.
>>
>> Why is text to a socket wrong?
>> Why is a messaging protocol better?
>
> Messages usually have things like CRCs. That way you have some
> assurance that the data wasn't corrupted along the way.
I came in late in this discussion -- most of the time, people who say
they're communicating using text over sockets are talking about TCP.
That's a reliable protocol; your bits do all get delivered, and you
don't need to implement the CRCs yourself. I noticed below he says he's
using SLIP, which to me also implies TCP (if it's a text stream!).
>> In the FPGA are a set of nine different, user selected peripherals.
>> Each peripheral has a set of registers that control its operation.
>> For example, the H-bridge controller has a register to control the
>> frequency of the PWM signal as well as the pulse width. �The actual
>> protocol to the FPGA is a SLIP encapsulated steam of command and
>> response packets. � Is this the kind of messaging protocol that you
>> would like to see? � �We are planning on documenting the register
>> sets and protocol, so maybe that's all that's needed?
>
> Yeah. I would definitely prefer that level of interface. That way I
> can do something more fancy if I like, but I can also be low-level if
> I like. Then if you want to get fancy, provide a library which
> translates a function API into packets, and a way of integrating the
> delivery of said packets. Lots of programmers (especially beginners)
> aren't as comfortable dealing with packet based protocols. But all
> programmers work with a C API (aka the C runtime library).
This makes a lot of sense. Really, even if you aren't a beginner, what
you want for device control is an API that provides the functions you
want. For a really good example, look at FUSE filesystems -- it's
really communicating between a daemon and the kernel over a socket, but
completely hides the details of the protocol from the programmer.
If you've got it available, you might think about using SCTP rather than
TCP or UDP -- it provides reliable, sequenced delivery of packets, so
for a lot of applications it's really the best of both of those worlds.
> By splitting (factoring) the code this way, you can move the "function-
> API to packets" to any processor/micro quite easily.
Yes.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Bob Smith
> I came in late in this discussion
Joe, the discussion morphed a little.... So there's an FPGA board
that has nine user-selected robot peripherals out of a field of
about 30 possible. There is a SLIP encoded protocol to the board
that does register reads and writes to the control and status
registers that define each peripheral.
Think about USB. You don't want to deal with *USB* for everything --
you want the USB subsystem to hide the USB connected peripherals
behind device drivers. My intent was to do the same for the robot
peripherals on the FPGA board. There would be /dev/dp/quadrature0
to get the values from the quadrature decode on the FPGA. I'd hide
the details of the SLIP protocol and the detail of the register set.
So my original thought was to build a couple of simple device drivers
that were shims. They offered up a /dev/dp/quadrature0 device node even
though the real driver was a user-space daemon talking over ttyUSB0.
My question was, is it better to use real device node or (like LIRC)
use a unix domain socket as the low level connection point?
If you have a stong opinion I would like to hear it.
thanks
Bob Smith
Joe Pfeiffer
This isn't a particularly strong opinion, but if I were doing it I'd
expose the device using your /dev/dp/quadrature (etc) approach, but
there's no real reason for there to actually be device drivers unless
part of your interface calls for ioctl calls -- they can easily be Unix
domain sockets, or even a FUSE filesytem.
Much more important is that there be a good, well-documented API on top
of however you expose the device that users can use without knowing
those details. The user just wants to be able to call get_quadrature(),
and not worry about how that function is implemented.