beacon navigating algorithm

Will Eyeam

I will be writing an algorithm for a robot to navigate beacons. I am using·the Propeller to write the code and was seeking some advice on whether to use loops or repeats, and the general structure. Here's my flowchart, and also an image of the beacon course:

SRLM

What is 'prey'? Also, aren't both 'loop' and 'repeat' just terms for iteration? On the section on the right (perhaps you could provide names for sections?) it says that you have five sensors total, but you only use an effective three. You could get more accuracy if you break down left into 'hard left' and 'soft left' and same for right. On the bottom section, what are the left and right sensors sensing?

Will Eyeam

the 'prey' is the beacon at the end of the course, possibly an RC car with 30kHz LEDs attached. There are 5 sensors in the middle of the bot, we might cut back to 3; these sensors will be detecting the 'prey' beacon at the end of the course. At the beginning of the course it doesn't detect the 'prey' so now it checks readings from 12 sensors total. 6 of these sensors are filtered to detect 10kHz, the other 6 detect 20kHz. Now check out the picture:
Now the program checks outputs from 6 sensors on Left side of bot: Left input. The 3-10kHz filtered sensors have outputs connected, so 1 pin will read this value via adc(call it S1). The other 3-20kHz sensors will have the same wiring, and the adc value(call it S2) will be subtracted with S1
>>Left beacons will be 10kHz, Right beacons are 20kHz
-Left input = S1 - S2; 'this will see if a left beacon is closer than a right beacon.
The Right side of the bot has the same 6 sensors with the same filters.
-Right input = S2 - S1; 'this will see if a right beacon is closer than a left beacon.
--LEft input > right input;· Now the program will determine if the bot needs to avoid a left beacon. If left>right, the bot needs to turn a little right. If right>left, the bot needs to turn a little left.
This is first draft flowchart, and I know I am missing a few other 'decision' blocks: but I plan on adding a block: (left or right input > max_input_value): make bot back up and change approach angle. And also I need to add a beginning procedure so the bot will roam forward if no beacons are detected.

erco

It's very difficult to predict how your software will work this generally. Certainly block diagrams show your intentions and how you hope it will work, but your robot hardware has so many variables that what works perfectly for someone else may not work at all on your robot. Differential drive, dual differential drive, ackerman steering, omniwheels, 3 wheels, 4 wheels, tricycle drive, wheelbase, tire size & diameter, drive floor surface, motor speed & torque, etc are all critical factors in how your robot steers. Optical sensors vary, too: discrete phototransistors, 38KHz IR receiver, what kind of view they have (narrow & shuttered, or wide open), response time, etc. Your beacons are also have variables. Strength, viewability, up high or down low, reflections, environment, ambient light, sunlight, etc. Long story short, build your hardware up front and allow lots of time for hardware & software revisions. That's entertainment. That's robotics.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Post Edited (erco) : 4/19/2009 7:34:02 PM GMT