🚀 go-pugleaf

ac94691@dunix.drake.edu (The Dark Kitty) writes:
: I just thought I'd share my current project with anyone interested.
: 
: Currently I am constructing a robot:
: 
A childhood dream! Go for it!

: The brains to control the on/off forward/reverse motor control are
: coming from a Franklin Ace 1200.  The motor control circuitry is out
: of one of the Ciarcia's Circuit Cellar volumes.
: 
Will the "brains" be attached to the robot, or will you be using some
sort of remote control scheme? I ask because it'd seem to be pretty
hard to debug the control program if you have to chase after the keyboard! :)

I've toyed with the idea of robotic control in the past, and it always seemed
that the best approach (if not the least expencive) would be to have a station-
ary computer do the actual decision making, and have a smaller, sencory input
and low level moter/steering control computer on board. You could the put the
robot on a lift of some sort (or just CHAIN IT DOWN!) so it won't wheel off
into the sunset while debugging the software.

I'm into packet radio, so I know the gear for the communications link is abund-
antly availible (though a bit pricey).

: I know it sounds like junk, but it has one virtue:  it's costing me
: nothing.  =-)  And it should be sufficient for chasing the cat or
: frightening small children.  ;-D
: 
I dunno. I'd say that your ideas have merit.

: Just thought I'd let you all know.
: 
: Anthony Clifton
:
Fred Floberg - N1GVA
email: ...!uunet!hsi!a3bee2!n1gva!fcf
 

In article <1993Jan4.191739.26583@n1gva> fcf@n1gva (F. C. Floberg) writes:
>Will the "brains" be attached to the robot, or will you be using some
>sort of remote control scheme? I ask because it'd seem to be pretty
>hard to debug the control program if you have to chase after the keyboard! :)
>
>I've toyed with the idea of robotic control in the past, and it always seemed
>that the best approach (if not the least expencive) would be to have a station-
>ary computer do the actual decision making, and have a smaller, sencory input
>and low level moter/steering control computer on board. You could the put the
>robot on a lift of some sort (or just CHAIN IT DOWN!) so it won't wheel off
>into the sunset while debugging the software.
>
>I'm into packet radio, so I know the gear for the communications link is abund-
>antly availible (though a bit pricey).
>

Ah!!!  I'm glad you asked because I forgot to mention it!  Yes, you
are absolutely correct.  The onboard computer will be a mother board
from an Apple compatible computer but the actual high level brains
will be a currently unused Mac 512.  The data link will be via modified
(you'll LOVE this) Mr Microphone equivalents that I acquired at close
out prices from Radio (Shack) Rip Off Store for $3.00 a piece!  The
modems will probably just be 300 baud modem chips from any major 
silicon distributor like Jameco etc.  This may ruin my dream of building
a no-cost robot but top price will be around $20 when I'm done if I
really go extravagant!  =-)

BTW, I actually got the plywood cut tonight and did some tests on one
of the radio transmitters.  I think it'll work ok though a 2 way link
will require two frequencies.  Oh well!  It's cheap...  ;-D

Anthony

In <1993Jan4.191739.26583@n1gva> fcf@n1gva (F. C. Floberg) writes:

>ac94691@dunix.drake.edu (The Dark Kitty) writes:
>: I just thought I'd share my current project with anyone interested.
>: 

[wheelchair-based robot description deleted]

>I've toyed with the idea of robotic control in the past, and it always seemed
>that the best approach (if not the least expencive) would be to have a station-
>ary computer do the actual decision making, and have a smaller, sencory input
>and low level moter/steering control computer on board. You could the put the
>robot on a lift of some sort (or just CHAIN IT DOWN!) so it won't wheel off
>into the sunset while debugging the software.

>I'm into packet radio, so I know the gear for the communications link is abund-
>antly availible (though a bit pricey).

   Packet radio?  Hummm.  Here's one experience I've had with it:
a few years back, I was the acting TA for a Clemson Robot Lab working on a
bomb disposal robot.  The students opted to use a Packet radio link, with
the packet TNC transmitting into a pair of simple walkie-talkies.  The main
robot had a STD based computer running the control systems of the robot, 
while the operator of the robot (this was a teleoperated system) ran the 
machine by operating a remote control panel attached to a PC.  The operator
used a remote TV screen to observe the robot's position.

   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.  

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

Dave Williams                                   | "What time is it?" "9:00AM"
 dwilliam@jabba.ess.harris.com                  | "What day?"        "Monday"
  "Huh?  What?  Could you repeat the question?" | "Go away.  Try me Tuesday"
    <mumble mumble> opinions <mumble mumble> mine <mumble mumble mumble>
--
Dave Williams                                   | "What time is it?" "9:00AM"
 dwilliam@jabba.ess.harris.com                  | "What day?"        "Monday"
  "Huh?  What?  Could you repeat the question?" | "Go away.  Try me Tuesday"
    <mumble mumble> opinions <mumble mumble> mine <mumble mumble mumble>

In article <C0HsFB.BvG@jabba.ess.harris.com> dwilliam@pizza.ess.harris.com (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.

Regarding buffering and packet radio, the more advanced protocols
(TCP/IP) use an algorythm that optimizes the packet size.

It tries to avoid small packets if possible, but will send them if it is
obvious that more data is not coming. (Nagel "tinygram" algorythym?)

This is discussed in the Comer TCP/IP book.

This allows both small packet (typically interactive) use as well as
large packets (file xfers, etc)

There will always be some latency, however. Even at 56k packet (which I
have connecting my unix machine at home to other ham's machines) it is
an issue, as the key up time for nearly all radios is much longer than a
typical packet. Thus any "non duplex" approach will suffer from this.

I can point you in the right directions for public domain code, etc.

Hope this helps!


 Alan Barrow  km4ba | I've seen things you people wouldn't believe. Attack
 jab@atl.hp.com     | ships on fire off the shoulder of Orion. I watched
                    | C-beams glitter in the dark near the Tannhauser gate.
 ..!gatech!kd4nc!   | All those moments will be lost in time -
         km4ba!alan | like tears in rain. Time to die.          Roy Batty