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
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
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
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.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.