Linux Network Joystick interface

I'm intrigued : ) It it wired or wireless ?

Well, it is a methodology to connect a joystick to one computer and have it usable by your robot.

Basically, you code your manual robot control system to use the "NetStick" API instead of a standard joystick API. Then, to use a joystick, you run "joysend" to read your joystick and send events to the robot. It can be run locally or on your network, or if your want, over the internet.

(Must have a good internet connection to avoid "deadman" condition where client application things the joystick isn't responsive enough)

While I am in no way advocating or encouraging its use, look at JAUS (Joint Autonomous Unmanned Systems Protocol). It is a high level protocol for transmitting and receiving robotic controls between an unmanned vehicle and OCU (operator control unit)

Look for my rant about what a hack job JAUS is in a later posting. :^)

BTW: if you are using wireless ethernet for control of your robot then don't fall into the trap of using TCP transport. Use UDP instead.

-noone of consequence

And what "trap" is TCP? UDP is fine, and all, but on a mobile device, I want to guarantee delivery of packets and know if they fail.

There are a lot of "tricks" to get a good server system running with TCP, but they are pretty pedestrian these days.

on a mobile device you don't want all those ack/nak signals floating across the network. They can saturate the network and cause messages to be queued up and processed in much longer than real-time: a problem if you're expecting to have joystick commands immediately processed. This is one case where QOS isn't a good thing because although TCP delivery is somewhat guaranteed, there is no guarantee (when) the message will finally get there.

Then there is the speed difference. TCP over 802.11b (what you'll use if going peer to peer) will be very slow. Figure as a best case UDP on

802.11b will give effective thruput of about 5mb/s whereas TCP (with no drops) will be less than half that rate.

UDP is really the only option for wireless command and control, but to further the discussion, wireless ethernet really isn't appropriate for wireless robotic control in real-time, especially if you want to do (beyond line of sight) control.

I disagree that TCP isn't workable for wireless control, but UDP is a good option where latency needs to be kept low and an occasional lost or out of order packet is tolerable. If you're sending something like joystick states updated every few ms, UDP is good. If a packet is missed an update is coming soon behind it. Include a sequence number in the packet, and unless there's a severe delay between packets go with the latest packet as current. If there are several packets lost in sequence TCP is unlikely to be getting through either.

On the other hand, if the protocol sends only changes in state most of the time you need the reliability of TCP, but are saving bandwidth by not sending redundant data. Depending on the nature of data to be communicated, TCP with such a protocol may deliver less latency on account of bandwidth.

While that is somewhat true, but, properly coded you can "timeout" on the API calls. If you have QOS issues, a networked API is problematic no matter what. Using TCP ensures that packets get there and if they don't, you know it.

Depending on packet size, maybe. If you are not sending a lot of data, i.e. filling the MTU , as in sending a file, but are sending and receiving relatively small packets, the bandwidth is not really an issue, even with

11b.

The best analogy I can come up with is the X Window System in UNIX. Human interface devices are VERY SLOW, keyboards, mice, and joysticks are nothing. Video and audio, now *that's* a lot of load.

Well, the video over IP is a problem as the video signal must be digitized and there is often a few seconds lag with an MPEG encoder. I need to find something faster, and that data is appropriate for UDP, absolutely.