NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/robotics/2800

Internet Message Format | 1993-01-07 | 3.7 KB

Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!umn.edu!noc.msc.net!uc.msc.edu!raistlin!shamash!ems!hollywood.ems.cdc.com!tbruseha
From: [e-mail] (Tom Brusehaver)
Newsgroups: comp.robotics
Subject: Re: My robot project.
Message-ID: <31474@nntp_server.ems.cdc.com>
Date: 7 Jan 93 20:37:52 GMT
References: <[e-mail]> <1993Jan4.191739.26583@n1gva> <[e-mail]>
Sender: [e-mail]
Distribution: comp.robotics
Organization: Empros Systems International, a division of Ceridian
Lines: 60
Nntp-Posting-Host: hollywood.ems.cdc.com

In article <[e-mail]> [e-mail] (Dave Williams) writes:
>
>   Packet radio?  Hummm.  Here's one experience I've had with it:
...
>the packet TNC transmitting into a pair of simple walkie-talkies.  The main
...
>used a remote TV screen to observe the robot's position.
>
I wont comment on simple walkie talkies, (CB maybe) but this idea has
always appealed to me.  Being a ham, I have never really wanted to do
it, but that might be a way for those who don't know about no code (or
who want to get by on $14 vs $200) to do teleoperations reliably.  Ham
radio also offers ATV (Amateur TV) giving NTSC broadcast capability.
Imagine teleoperations using head mounted displays, and 2 video
cameras.  Talk about vitural reality!

I'd be interested in hearing about the RF shielding used.  I imagine
the simple walkie talkies were quite suseptable to noise from the
computer, motors, and other stuff.

>   The stumbling block for this system was the radio link.  The packet radio
>worked very well, except for the fact that it tended to have an extrememly
>long latency time.  As a result, commands coming from the control system
>would get buffered up in the TNC, then transmitted in one long burst.  This
>made the robot nearly uncontrollable, since the was nothing even approaching
>real-time operations.  Unfortunately, the students hadn't discovered this
>problem untill way late in the semester, and they never found out how to
>solve it.  Next year's group went with a tethered system, so we never found
>out any more about the packet system.
>
Most TNC's that I have delt with allow changing packet sizes, and
transmit character.  Usually the packet size is rather large, and the
transmit character is return (or linefeed).  When this character is
recieved by the TNC, the TNC transmitts the current packet in the
buffer.

Depending on the command language used (base => robot) the carriage
return could be appended to all the commands.  The UI could do some of
the work.  I could see a joystick attatched to a PC sending commands
to the remote system in terms of f100<cr> (forward 100, relative
position, return).  The SBC would see this as f100<cr>, and process it
as move forward at rate=100.

>   Since you're familiar with packet controllers, I'll ask you:  do most
>TNC's have a way to specify transmit latency?  If we could get the TNC to
>transmit packets as soon as it receives them, the packet system looks like
>it could be really useful.  As is, it's just too slow a link to do any real-
>time control.  (At least for teleoperated systems - something with more
>intellegence on the actual vehicle may be able to stand more latency in the
>transmission link...)
>

I think if you set your packet size=1, that the TNC will pretty much
transmit as soon as the character is received.  I haven't actually
tried it, but it might work.  Also in transparent mode, There is less
overhead on the receiving end.  I used my TNC at home in transparent
mode attatched to my sun, and a laptop, to setup a UUCP connection
from the UUCP sending site.  Worked pretty well.

Tommy B.