Shop OBEX P1 Docs P2 Docs Learn Events
Request for assistance, QTI sensors (3) — Parallax Forums

Request for assistance, QTI sensors (3)

cra18cra18 Posts: 1
edited 2011-11-15 00:29 in Accessories
Dear Parallax Community,

I'm hoping someone can help me work out a dilemma I'm currently having with the Parallax QTI IR sensors. My BOE-Bot has three mounted underneath the chassis.

One of the objectives that the Bot must perform is to line-follow around a black circle (the "black line" is from permanent marker, and the background surface is a stiff green foam). The code (attached; specifically, the "lineFollowing" subroutine) was adequate for this task. However, recently we appended a 2x16 LCD display to the rear of the Bot, and now line-following no longer works (with the same code). As best I can tell, the Bot will make small turns toward the line for a brief moment or two, and then fall off the circle tangentially. This happens every time.

I'm really at a loss as to what is going on, since the code is not complex. I guess I am asking:

(1) Might the QTI's be too high (clearance too large)? What is the ideal clearance?

(2) The additional weight from the LCD seems to make the BOE-Bot bounce vertically slightly as the DO...LOOP construct hits the PAUSE commands. Could this be responsible?

(3) Is there any modification to the PAUSE commands that could be made to make the QTI sensing more accurate? I do NOT care how fast the BOE-Bot follows the line. (I actually do not fully understand the reasoning behind including PAUSEs at all, but they were in the sample code. What they definitely do is slow down the line-following process).

(4) Is there any modification to the PULSOUT commands that I could make?

What I am thinking now is that, since the Bot falls off the circle tangentially, it seems as though the degree to which it tries to correct itself with a pivot (either left or right) is not sufficient to get back to the line before the case % 0 0 0 takes over and it goes forward.

Thank you in advance for your assistance.

[EDIT] I just changed the protocol for the cases % 0 0 0 and % 1 0 1 to be PAUSE instead of forward. Hopefully this will help when I try to troubleshoot it later this week.

Comments

  • SRLMSRLM Posts: 5,045
    edited 2011-11-15 00:29
    Looking at your code, I noticed:
    1. You shouldn't initialize the LCD in your main loop. It will wack up the LCD (programatically, not permanently) and it's unnecessary.
    2. Your main "loop" has a 'return' statement, but it's not returning anywhere. Replace it with a 'GOTO main' (ps: pbasic isn't like C++ or Java where you need a return at the end of main...)
    3. Your line following subroutine has an infinite loop. The DO should be followed by a condition, or even better remove that particular loop structure completely.
    4. Your movement routines (forward, backward, etc.) have a pause of 80 which seems a bit high. IIRC the servo time should be around 25 on the vanilla BS2 (but check! It's different for different BS2s...)
    5. Your hold routine is missing the pause, which should be identical to whatever value #4 results in.

    Overall, your code needs restructuring. You have too many different parts going on, each of which appears to have been coded individually and then mashed up together. Your code needs to be streamlined and thinned out. I would start by using a main loop that has the form of
    main:
       GOSUB check_qti
       GOSUB calculate_action
       GOSUB output_servo
       GOSUB output_LCD
       PAUSE delay
    goto main
    

    Then, within each block it has a clearly defined task, and no significant pause statements. The pause delay value above should be calculated as follows:

    delay = servo_refresh_rate - main_loop_execution_time

    Also note that serial display takes time to transmit the data, so for a faster transmission simply transmit less data. Finally, don't try to do everything at once. I'd start with getting the output_LCD routine working, then the output_servo routine, then the QTI and calculations routines. By doing so you can limit any new bugs to code that you just produced.

    Good Luck
Sign In or Register to comment.