Boe bot with QTI's and Ping
Ronbert
Posts: 20
Hey all,
I'm building a boe bot that follows lines with 4 QTI sensors and when an object is placed infront of it the ping sensor will pick it up. The boe bot will veer off course to avoid the object and find it's way back to the line. I'm just wondering if anyone has some information for me on how I might accomplish this? Maybe some documents or instuctional videos?
Obviously I'm not going to find a finished code, I'm just looking for some proof concept ideas so I can engineer my project.
I'm building a boe bot that follows lines with 4 QTI sensors and when an object is placed infront of it the ping sensor will pick it up. The boe bot will veer off course to avoid the object and find it's way back to the line. I'm just wondering if anyone has some information for me on how I might accomplish this? Maybe some documents or instuctional videos?
Obviously I'm not going to find a finished code, I'm just looking for some proof concept ideas so I can engineer my project.
Comments
All it does is center the servo and then go forward in a straight line until the ping sensors sees somthing 7 centimeters infront of it.
When this condition is detected it activates the avoidance subroutine which as of right now just drives in a square around the object. IE: 90 degree right turn, forward shortly, 90 degree left turn, forward long, 90 degree left turn, forward shortly, 90 degree right turn, check ping.
If after the square had been driven the ping sensor notes a distance over 7 centimeters it continues on its way to start all over again.
EDIT: I changed the code slightly to do a half circle around the object instead of a square
Object avoidance.bs2
A specific problem I'm having is when my qti's pick up 3 sensors and should correct the boe-bot back to the line, the machine freezes instead.
The reason the bot freezes is (probably) because the code has a list of conditions, and the particular pattern does not fall in that list. The two most direct possible solutions are: (1) add a CASE ELSE statement to catch any patterns not provided for in the other cases, or (2) add CASE statements for the other binary patterns.
Andy
EDIT: This is driving me nuts! Sometimes the bot corrects just fine and sometimes it doesn't! I can't figure this out.
EDIT: So I got a little creative and moved my maze close to my PC and hooked an extra long usb core into the bot so I could debug the QTI sensors and what I found was that instead of registering 3 or 2 sensors the only sensor actually being registered is the 1 of the middle sensors.
To combat this I did what Andy said and simply went to my main program and added
CASE ELSE
GOSUB Forward
This allows the bot to go forward until another combination can be found, in this case after a moment the second sensors will be picked up and the boe bot will do it's correction.
Good sleuthing!
I will mount two servos to the back end of the boe bot and hand make two metal claws. One to be mounted on each servo, the pair will form a crab claw. When the ping sensor detects an object the boe bot will do a 180 degree turn, back up slightly and grip the object. Then it will drag the object off the maze and go back to the line and continue along it's merry way.
What do you think?
The only potential issue I have is that we have no more standard servos and it's to late to order any so I'll have to use two continuous servos with strict timing.
Right now I'm using cardboard, it works okay for testing but in the long run it looks shoddy and the claws wear down quickly from bending and bumping into each other. Any ideas on some light weight, strong, cheap material I could use? Claws are about 2.5" long.
I've also notived repeatability is kind of low as well. Seems like theres a 25% chance of things going wrong and I have to restart the maze... Frustrating especially with presenting this in a couple days.
For example I want Board1 to send out a high voltage to Board2, Board2 will sense this voltage and output a 1. Board2 will then see that 1 and perform a command like IF (voltage = 1) THEN goforward
Question is no longer necessary, found the problem. Will post how to remedy later.
10 k
20 k
5 V
You can connect the point where the 10 k and 20 k resistors meet to another I/O pin. 0 V will be read as low; 1.4 V will be read as high.
For a more robust approach, a comparator can be used. ...discussed in Chapter 9, Activity #1 in http://www.parallax.com/sites/default/files/downloads/122-32225-Understand-Signals-PropScope-Text-v1.0r2.pdf
Andy
To be clear, I do mean the pins next to the breadboard, not the pin block located towards the back of the bot.
If it's just two I/O pins allowing different boards to exchange signals, what you have seems fine. The two potential issues are common ground and I/O accidents. For common ground, there needs to be a GND (might be labeled Vss) connection from one board to the other. You can also just use wire with alligator clips to connect corner mounting holes of both boards. With a common ground, 5 V on one board will also be 5 V on the other board. Without the common ground, 5 V on one board could mean who-knows-what on the other board. I/O accidents are if the program on one board tries to send a high signal and the other tries to send a low to the same wire. If you only use a wire, there could be microcontroller I/O pin damage. A 220 ohm resistor in series between the two pins would prevent that damage possibility.
Also in my last post I talked about using CON directive, this does not work. I don't posses the knowledge as to why, maybe something to do with CON being a variable and not a voltage. The code now goes something like...
IF (distanceFromObject > 3) THEN
HIGH movement_pin
ENDIF
then on the main board (the one with servos)
IF (movement_pin = 1) THEN
GOSUB Forward
ENDIF