SyBorg

Let's Make Robots Robots
1

Differentially-steered robot with 12x5 LED front display, sonar "eyes", text-to-speech, self-docking charging, etc. In progress, but mostly done.

The access hole in top is open in the main photo; generally there is another small panel on top of the access hole that contains two IR detectors with a thin "vane" between them -- these are used for detecting direction to the charging-station beacon. The same detectors are used for receiving coded IR messages from the other 'bots in the fleet. Above that is usually a birch table-top -- basically it's like a small coffee table on wheels.

The front display shows many expressions (bitmaps of lips, open/smiling/eating mouths, smileys, etc.), but can also be used as a debugger to show distance on sensors. Additionally it support scrolling text, so that (sometimes) when he speaks the same words show up on the front display. In back (not shown) is an IR ranger on a servo used for detecting both rear obstacles and side obstacles when turning (as the drive wheels are very far forward on the platform, the rear swings "wide" when turning, so the tail really needs it's own sensor). 

Under the front "nose" is an IR ranger pointed down at an angle -- this lets the same detector "see" cliffs/drop-offs (distance too large) or objects that are low and close that the sonars may miss. This is a nice setup because it gets around the <4cm limitation of the Sharp rangers -- an object that is *very* close registers a false *long* reading -- which is a cliff to the 'bot -- so the results are the same. Basically, if the ranger's distance is not within a pre-defined "sweet spot", then the 'bot presumes there is a low object or that there is a cliff.

The sonar's are on pan/tilt servo assemblies and can actually point all the way out to the sides -- so their sweep is quite good for general obstacle detection. 

A pair of light sensors, an R/C receiver and a real-time-clock round things out (the RTC is very nice -- he announces the time on the hour while showing an analog clock on the front display, reminds me when my favorite radio programs are on, sings happy birthday to members of the household, and with the battery backup, it's a nice why to have some non-volatile RAM with fast access and no write-cycle limitations, etc.). 

Basic structure of programming is subsumption AFSM, but with a lot of little tricks like self-tuning setpoints for obstacle detection and the like (a *must* if your 'bot will roam through areas of the house where the materials it encounters change) 

Sorry, this photo is actually about a year old and he looks a little different. I've been installing quadrature encoders for velocity control and odometry (theta, x, y, distance/heading to target, etc), so I'll try to get some current photos in the next week or so.

Brief list of electronics:

main micro - Basic Stamp 2p40

peripheral micros - one PIC (A/D, PWM, extra pins), two SXes (servo control, motor control)

peripherals - Emic TTS module (speech), Devantech MD22 motor controller, cheapo R/C receiver, DS1307 RTC, 32kbit external EEPROM for speech strings, control codes and bitmaps of pictures and text chars (front display). 

sensors - two Parallax Ping))) sonar units, two Sharp IR rangers, two CDS cells, two Panasonic IR detectors, one high power emitter, two CDS light cells (A/D voltage), one A/D for battery voltage, four Hamamatsu emitter/detector assemblies for encoders, assorted digital inputs for things like positive connection to charging station, etc.  

 

See a brief video here: http://www.youtube.com/watch?v=9PGgkRUSlDY&feature=channel_page

 

1279×1027
 

hangs out

  • Actuators / output devices: 12v DC gear motors, pan/tilt assemblies for sensors
  • Control method: Totally Autonomous
  • CPU: Basic Stamp 2p40, SX
  • Operating system: embedded apps
  • Programming language: Basic, Assembly
  • Sensors / input devices: sonar, IR rangers, CDS cells, various digital i/o
  • Target environment: indoor
This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/syborg
2

Need mooor Info.
Need mooor Info.

3

Posted a bit more info. Plan
Posted a bit more info. Plan to have pics, schematics, plans, code, etc. up sometime this month.

4

**Looking forward to it. Im**<br><p>Looking forward to it. Im interested in your AFSM which means something-Finite-State-Machine right? I had a quick look at some pretty vague stuff on the web but couldnt make head or tail of it. It was very broad and I just didnt understand how to translate something like that into C. Do you know of a good place to start? (AFSM for Dummies).

5

Augmented Finite State

Augmented Finite State Machine. Finite State Machines are bread and butter – if you grasp the basic concept, then language doesn’t matter. I use state machines of all flavors in all my projects (professional and otherwise), micro and high-level.

Is there a breakdown of state machines in the “tips” or “forums”? Just searched a bit, nope.

This might be a good explanation of the concept: http://www.devmaster.net/articles/fsm_intro/

In most of my ‘bots, small modules that are “black box” state machines handle all the behaviors, reflexes, etc., and then those modules are set up in a subsumption order – which ever module writes output values (e.g. motor speeds, light shows, voice, etc) LAST wins! e.g.:

while(1) {

talkToRoom() ; if the state of this FSM is talking, then write talky output values to buffer

runStraightAhead() ; what that said, but maybe this FSM sometimes turns slightly, or stops for a while

avoidWalls() ; if this FSM detects walls, it runs avoidance behaviors

avoidCliff() ; what that said

checkBattery();

}

So even if talkToRoom and runStraight “write” moving/talking values to the output buffers, those values get “trumped” by the output of avoidWalls and avoidCliff IF THOSE MODULES’ states require action. That’s where the black box FSM comes in. Augemented means it has a timer and/or will “sleep” and is not a straight response to state or state change. Here’s a simple outline example of an avoid-type machine. Remember this would run EVERY TIME through the main loop, but only gets a crack at controlling the output after the non-reflex behaviors and before behaviors that are more important (dead battery, cliff, etc.)

; pseudo code

if ( state == 0 ) {

if ( sonarLeft < 100cm || sonarRight < 100cm ) {

state = 1 ; go to next state

talkOut = “oh gosh an obstacle”; this only get said ONCE on the state transition

}

} elseif ( state == 1 ) {

if ( sonarLeft < 100 && sonarRight < 100 ) { ; whoa serious obstacle

avoidTimer = 10 ; back up for ten seconds, so set timer for subsequent state

state = 2;

} elseif ( sonarLeft < 100 ) {

motorTurn = 0 ; start turning right

} elseif ( sonarRight < 100 ) {

motorTurn = 1; start turning left

} else { ; both must have “cleared”; back to state 0

state = 0;

}

} elseif ( state == 2 ) {

if ( avoidTimer > 0 ) {

motorTurn = 128 ; straight

motorSpeed = 0 ; reverse

avoidTimer–;

} else {

state = 0;

}

}

Of course, my own code in implementation is quite a bit more dense and complex (e.g. the outline above would always favor a left obstacle; I generally check both and see which has a higher error, and turn that way), but hopefully that gives you the idea.

6

Really interesting home bot!
Really interesting home bot! Have you read through anything about IsoMax, a Forth based implementation of state machine structure? I’ve used Minpods and IsoPods on a few robots, and made some very basic state machine programs.

7

Looks like a really well

Looks like a really well developed bot. Is it going to do anything in particular or just be cool and have fun?

I laughed when he said "something is near my rear" =p

8

What and Why

Oh, he mostly hangs out and keeps things lively in the office. He’s up on the bench now while I tweak motor control, odometry and encoders so he docks properly with his nest (which is itself a “static” 'bot with it’s own expression, pesonality, etc).

Originally he was conceived as a rolling coffee table that would follow me around with my ashtray, my drink, etc., but then he evolved into something much more expressive and “self-contained”. He does lots of stuff it would probably take hours to video, since there are things he only does when he feels like it, or when circumstances are right (like a very crude video game where you put your hands near his two sonar units, and use the distances between your hands and the sonar to line up two cross hairs on the front display – when the lines meet, there’s a little flash explosion and your score is tracked. Do it enough times and he does a dance and congratulates you. It’s pretty neat because it’s a good way to show folks what sonar is and what it does. That sort of thing.)

9

charging
what batteries did you use and what was your circuit for charging?

10

**lovely ! **

  that’s one gr8 robot you have there  ! :slight_smile:

11

Battery/Charger

It’s actually a regular lead-acid garden tractor battery. Lots of power (good) but highly dangerous, really (bad). When $$ allow I will swap out for a beefy sealed lead-acid or gel-cel battery, but for now it will have to do.

 Charger/nest is an LM350 set up as a constant current charger (which is fine for lead-acid, nothing fancy) at around 14v ~1.2A. Since the 'bot has an on-board ADC for measuring voltage, it decides when the battery  is charged and backs off the nest. However at that current, the battery could be left on quasi-indefinitely, as it’s in the trickle-charge range.

I think I have the schematic for the nest around here… yeah…

 Note that this required a pretty big heatsink on the LM350 and a pretty big heatsink on the power resistor, with good ventilation in the cabinet. The two diodes in the charger portion help drop the Vin voltage a bit (I’m using a 16v 2A power supply scavenged from an old HP printer) and help prevent short-circuits across the charger contact bands. The 'bot has a similar diode setup for the same purpose. The diodes are 6A rectifier and get quite warm to the touch, but don’t require heatsinking if there is lots of free air all around the component – i.e. mount them so they sit high above the board/terminals so air can circulate underneath as well.

synestSchem.png
synestSchem.png1020×770 7.3 KB

 

Full size schematic click here