make Boe-Bot follow a line forward and backward
Hiiii, I am doing a project using Boe-Bot in school. We have to make Boe-Bot follow a line forward and backward. My boe-bot follow the line forward but I cannot make it follow the line backward. Hope some one can help me on this...thank you..
Post Edited By Moderator (Chris Savage (Parallax)) : 6/14/2007 2:35:15 PM GMT
Post Edited By Moderator (Chris Savage (Parallax)) : 6/14/2007 2:35:15 PM GMT
Comments
It would seem to me that you will either have to turn the BOE-Bot 180 degrees so it always is in a "forward attitude" or use two sets of I/R sensors, presuming that's how you're following the lines.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am using 3 QTI (IR) sensors. And theres no way I can change any of the settings coz we are making the robot for a competition. And I don't think I can turn the robot 180 degrees coz the actual robot will be 25Kg and 90cm tall, the same time there's not enough space to turn it....
Isn't there any other way that I can move it backward, sensing the line at the same time?... I used the codes in the manual to make it move forward and try to used the same way to make it backward by changing the pulsout...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
I am buiding a autonomous robot.
Why can't you sense the line while going backward? You do when you are going forward I hope.
You can not change settings .. what does that mean? Can you change the program?
Ed
I can change the codings , but I cannot change the number of sensors or the place of the sensor....
control of the servo's
Ed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A complex design is the sign of an inferior designer. - Jamie Hyneman, Myth Buster
But the thing is we already finished the structure of the robot, so I am not sure whether we can have sensores at the back.
Post Edited (cutey) : 6/17/2007 6:25:23 AM GMT
SELECT qti
CASE %000 ' Forward
GOSUB Front
CASE %010 ' Forward
GOSUB Front
CASE %011 ' Pivot right
GOSUB PRight
CASE %001 ' Rotate right
GOSUB RRight
CASE %110 ' Pivot Left
GOSUB PLeft
CASE %100 ' Rotate Left
GOSUB RLeft
CASE %111 ' Forward
GOSUB Front
.
.
.
.
Back:
PULSOUT 13, 650
PULSOUT 12, 850
RETURN
Front:
PULSOUT 13, 850
PULSOUT 12, 650
RETURN
PRight:
PULSOUT 13, 850
PULSOUT 12, 750
RETURN
RRight:
PULSOUT 13, 850
PULSOUT 12, 850
RETURN
PLeft:
PULSOUT 13, 750
PULSOUT 12, 650
RETURN
RLeft:
PULSOUT 13, 650
PULSOUT 12, 650
RETURN
At least from my own point of view, although the existing code may work, there is a physical timing problem. By the time it senses that it is off the line, it's quite late in the game to be trying to make corrections. I would expect that timing problem to exhibit itself as a good deal of wandering, or as a comple inability to "stay on track".
To view the problem in a differnt light, one might also think of it as a late feedback problem. By the time you get the feedback (it's off the line, and has been off it) and begin to correct for it (now it's even further off the line, but that's yet unreported!), the correction is made but it's under-corrected, and now even further corrections must be made. Eventually you may even over-correct, making mattters even worse.
I hope that made some degree of sense.
Regards,
Bruce Bates
Post Edited (Bruce Bates) : 6/17/2007 7:51:57 AM GMT
Cutey
did you really try to replace all gosubs in the select qti code?
forward -> back
pivot right -> pivot left
rotate right -> rotate left
pivot left -> pivot right
rotate left -> rotate right
Should work .. more or less
good luck,
Ed
For those who are adventuresome, and have time on their hands there IS one way one might try do it IF the light source on the QTI sensor was strong enough. You MIGHT be able to snap a set of mirrors into place so that they could ... look-behind. This way you have reduced or eliminated the nasty time lag which otherwise causes the problems.
I don't have it quite worked out in my mind, but another, similar direction might be a rotatable, mirrored prism. The QTI would then be center-mounted and the prism could be rotated towards the front or towards the rear, as required for the current mode of travel.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
As an example, suppose moving forward and the qti readings are 010 = on coarse.
nxt thing what happens is 011 = line is a the right from the center so you need to correct to the right BUT
due to overshoot, the nxt measurement is 000 and the line is at you left.
Since 000 is an acceptable state in your case you move forward and as a result further away from the track.
What you could (should) do is after the sequence 011 000, move slowly to the left and keep seeking the 010 reading.
do not accept an 000 as and OK to go ahead.
What could help also is lower the speed in the SUBs pivot and rotate. They might work now ok in forward mode but not in backward mode.
That depents on the location of the sensors relative to the wheels.
Most likely, you wheels are in the back and the sensors in front. Result, when moving backward the sensors move faster to the left or right
when a pivot / rotate is activated.
Lots of things to do but since you are running out of time .. try much lower speed in backward mode.
Good luck,
Ed
hi SkyWalker49 - I did try to do it, but didn't work.
what happend was,
when the robot move forward, if 100 it becomes 010 and then 011 then 010
but when moving backward , if 100 it becomes 010 and then 110 then again 100 so it always go to one side...
And at the beginning there is a space where no lines are there to follow so I must command my robot to move fwd and follow the line.
Post Edited (cutey) : 6/17/2007 11:13:44 AM GMT
in principal you have the same problem in going forward as in going backward except that in FW the error goes from left tot right
or reverse and in going BW the errors is always at one side. In going FW you get 100 010 and then 011 .. why 011, why does it not stay at 010?
Why, because the correction (rotate or pivot) changes the course of the bot and once you get an OK reading (010) you move forward
in the change direction but what one should do is to re-align the bot again with the line to follow.
That is easier said than done but nevertheless, this is the fundamental cause of what happens.
On option could be - but I never tested it - after correction and hitting the OK reading (010) very very slowly move back in the reversed
sense for as many pulse as you used during the initial corrrection BUT lines are not always straight :<))) and than this will no longer apply.
Ed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
absolutely.
.·· The speed of position change of the sensor on the circle
.········ with midpoint eq. to center point of the wheels
.········ radius = distance between that center point and the sensor,
.·· is linear to the radius.
Ed
Post Edited (Skywalker49) : 6/18/2007 3:29:51 PM GMT
don't know how you handled your project .. hopefully it went OK.
Here a visualisation of what I wrote about the differences between moving forward and moving backward.
Keep in mind that what I do is simulate your experience·with IR statuses:· FW 100, 010, 011, 010·· and BW 100,010,110,100.
The width of the line and the location of the sensors influence the track which will be followed and also the sequence of IR sensors triggered.
For example, when moving from 2.1 to 2.2 you could go from 100 to 011 immediately if you rotate very strongly.
On the other hand, if the sensors are much further apart compared to the width of the line or you rotate very slowly, then it is possible that you never have a 011 situation but go directly to 001 since 010 is interpreted as OK, move straight ahead and you can see in 2.2 that moving
ahead will lead to 011 or 001.
What one should do is that once a 010 is detected, the bot should be rotated to be in parallel with the line again but that is not a easy task.
How to keep track of you previous movements and adjust for those ?
It would be nice to have some formulas to help to navigate.
Ed