Shop OBEX P1 Docs P2 Docs Learn Events
Boe bot with QTI's and Ping — Parallax Forums

Boe bot with QTI's and Ping

RonbertRonbert Posts: 20
edited 2014-04-07 11:42 in Learn with BlocklyProp
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.

Comments

  • RonbertRonbert Posts: 20
    edited 2014-02-24 12:20
    So far I've done the code attached below...

    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
  • RonbertRonbert Posts: 20
    edited 2014-03-12 12:57
    Finished a maze follower code, it's a highly calibrated and customized version of the mini stamp tutorial code posted as a sticky at the top of this thread. I've also implemented my object avoidance code above into my line follower code but am having trouble getting all the sensors to work together... any and all help appreciated.

    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.
  • edited 2014-03-13 13:56
    Great work Ronbert!

    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
  • RonbertRonbert Posts: 20
    edited 2014-03-17 11:01
    Thanks for the response Andy! I'll be working pretty deeply on the bot today. I thought I had the condition in there but for some reason it's still doing the problem so I'm gonna do some more work :)

    EDIT: This is driving me nuts! Sometimes the bot corrects just fine and sometimes it doesn't! I can't figure this out.
  • RonbertRonbert Posts: 20
    edited 2014-03-17 12:36
    I think I may have narrowed the problem down but I'm not sure what to do about it... The problem seems to occur in my Turn_Check subroutine where for whatever reason, the boe bot stops and then doesn't execute the move forward function.

    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.
  • Steph LindsaySteph Lindsay Posts: 767
    edited 2014-03-18 11:31
    Ronbert wrote: »
    ...

    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.

    ....

    Good sleuthing! :)
  • RonbertRonbert Posts: 20
    edited 2014-03-19 13:07
    Sorry for spelling errors. I'm usually in a frenzy when I write these. So I got the boe bot moving good but my insturctor has said I need to add something original, and with 3 weeks left till semester end and a lot of worrying I found my perfect adition to this bot. I've decided I will no longer do a half circle around the object the ping))) sensor detects but rather now... and hold onto your seats folks.

    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.
  • Steph LindsaySteph Lindsay Posts: 767
    edited 2014-03-19 14:03
    Interesting idea! You will have some fun mechanical, electrical, and programming puzzle pieces to work with.
  • RonbertRonbert Posts: 20
    edited 2014-03-21 10:45
    Made some mock claws today, work perfectly. I'm gonna start taking pictures to post so people can see visually what's going on.

    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.
  • Steph LindsaySteph Lindsay Posts: 767
    edited 2014-03-25 10:49
    Maybe check the recycle bin in the kitchen...how about thin plastic cut from a lid to a tub? Think cottage cheese, quart of yogurt, etc.
  • RonbertRonbert Posts: 20
    edited 2014-03-28 10:45
    I used some very light alluminum for the claws, I also mounted a back facing ping to detect distance between the claws and object. When distance is less than 3cm the claws grab. Been highly busy so no time for pictures yet.

    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.
  • RonbertRonbert Posts: 20
    edited 2014-04-02 12:46
    How would I go about sending a voltage of 1.4v out to another basic stamp board to be interpreted by another pin as a high?

    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.
  • edited 2014-04-02 13:26
    (0 or 1.4 V)
    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
  • RonbertRonbert Posts: 20
    edited 2014-04-02 15:16
    Andy, I hooked a jumper from PIN 0 on one board to PIN 10 on the other board and in program1 I put something like PIN0_Symbol = (CON that equals 1) and then in the other program put IF (PIN10_Symbol = 1) THEN go forward. This seemed to work fine, am I going to be damaging the board?

    To be clear, I do mean the pins next to the breadboard, not the pin block located towards the back of the bot.
  • edited 2014-04-02 16:09
    Is this a different question, or related to the previous one?

    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.
  • RonbertRonbert Posts: 20
    edited 2014-04-07 11:42
    I've made some good progress, I'm going to update this entire thread by the end of the week with pictures and code. I'm just wondering if I should start a new thread in projects that details what the bot is and does or if I should just update this thread?

    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
Sign In or Register to comment.