Linux drivers for robots: /dev or sockets ?

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

Take a look at two open source projects already used for robot control: The Willow Garage robot operating system ("

")and "Player/Stage". ("") 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

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

Has anybody sucessfully downloaded ROS yet? I tried and their configuration script was littered with bugs.

Agreed.

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

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

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.

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

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.

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

Hi Bob,

Messages usually have things like CRCs. That way you have some assurance that the data wasn't corrupted along the way.

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

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!).

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.

Yes.

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

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.