Little help Please (with dead reconing code)

[Xufer]

Does anyone have any dead reconing code they could post inorder to give me some ideas that could lead to a working dead recogning code i continullay draw blanks when i go to write the code? how do i set up the timing as far as knowing how many loops or second can past i know i've seen post talking about the timing but i could use a clarity as far as they go.


Thank you,

John.



im sorry if this seems like a repeditive post but im having alittle trouble conceptualizing.

[KenWittlief]

the timing of the loop, or how hard you tell your bot to turn when you detect you are loosing the line, depends on how fast your bot can turn, how fast its running, and whether or not you just hit one of the spots where the line changes direction.

line tracking with two sensors is simple -you space them out so the are on opposite sides of the line, and you put your robot pointing in the direction you want it to go

start the robot moving straight

if the right side sensor sees the line then you have turned to the left, so you tell it to turn right until it no longer sees it

and same (opposite) for the other side

but thats where you have to try some values, see how your bot responds, and adjust the amount of turn, the speed of the robot...

there is also the possibility that the sensor will see the line, but not be able to turn fast enough, and cross over it completely (if its going too fast)

all these things need to be tested with your machine and you need to tweak your settings - also, if you put more than two sensors on the bot, you can cover the possible variations with different responses.

[MisterX]

Sorry, to John if it seems that I am stepping on his toes and sorry if John's post sounded a little unclear but we already have a successful line tracker that we just finished earlier today (our code is posted in "Line seeking help" ) I believe, if I remember correctly, that John is searching for the dead reakoning code where the robot operates practically blind and just follows code saying go this way for so long than this way for so much long.

[KenWittlief]

ok - am I going brain dead or did you edit your first post? For some reason I thought you were looking for line following code, but it says plain as day "dead reconing"

?!

[Xufer]

Originally Posted by KenWittlief

ok - am I going brain dead or did you edit your first post? For some reason I thought you were looking for line following code, but it says plain as day "dead reconing"

?!

nah i didn't edit the post but i still do need help im having a little (LOT) bit of trouble, so if anyone could help thankyou..

[MisterX]

I dont mean to be beating a deadhorse ( well really a dead post) but litterally ANYTHING that somebody out there in CD land would EXTREMLY help us with our dead reaconing. So plz if anybody could give us SOMETHING on dead reakoning we all would be very much appreciative...

P.S. I'll hook ya up at UTC regionals or Nats with some trinkets or stuff if it works or helps

[bstempi]

Ok, I don't have any exact code on hand, but our bot from last year ran on only dead reconing. There are a few things you need to take into concideration:
1) Timing vs. absolute positioning
2) Does the bot drift? Can you stop that?
3) Acceleration/deceleration and it's effect on the bot

Learning from last year, doing dead reconing based soley upon time is a bad idea. Our primary problem was drift. On paper, our timing worked, but because when we turned one motor wasn't powered, it drifted and threw everything off. In other words, saying pwm13 = 254 for half a second isn't a good idea.

What I would recoment would be a way of absolute postitioning. Instead of relying on time, give your bot a way to know exactly ( not using time x speed) of where it is. One way to do this is by using encoded sensors (such as in a mouse). By making your axis spin an encoded sensor that is hooked up to the FRC, the bot can tell how many revolutions it has traveled. By using some simple algebra using your wheel radius, you can find out how far you travel with each revolution.

You can also do a few neat things with this. For instance:
1) if your bot is stoped, and someone pushes it, the bot can sense that and pe programmed to fight back
2) you can use it to prevent drift. If pwm 13 is @ 127, and another is @ 254 (simulating a turn like a tank), then the bot can sense if it's drifting and can either prevent it by fighting back or can make up for it.

So basically, now that you're armed with this knowledge, you can beging to program some dead reconing code.

You can (using coded discs) tell the bot to go x number of revolutions @ a certain speed as opposed to telling your bot to travel at speed 254 for 2 seconds. I'm not sure how clear this is going to come across, but I'll be sure to check this thread again. Feel free to PM me.
~Brian

[Xufer]

I had thught abot the possibilitie of drifing as well as the costing from the winding down of or motors but i plan on settin a small revers flow for .2 seconds inorder to have the motor wind down quicker then turn. i do need to know how to get a motor running for so many second then stop becuaewe need to raise our arm durring autonomous mode aswell as get it to swing to remove those 10 point balls and i want to have a backup autonomus just incase our line seeking doesnt work. I have been toying with IR but, im not exactly sure how to implement the IR beacon tracing, it seems s though the robot would not work as exact.

what i really need to know is how to:
1. get a motor to spin for X-many seconds at Y-many speed
2. get each line to execute at the right time.
3. get the code to execute 2 lines a the same time for differnt lengts of time and power

all of which im havng trouble figuring out, so if anyone could give me a hand i would appreciate it !!

[Astronouth7303]

Aren't there some wait functions somewhere? those would do nicely.

[KenWittlief]

I dont have any C code for dead rec, but I can psudeo code for you and you can map it into C

if autonmode = false then /* initialize the auton variables*/
begin
sequence = 0
autontime = 0
end

else /* do the auton stuff */
begin

autontime = autontime+1 /* increment the loop counter */

if sequence = 0 then
begin
motor pwms = 254 /*full speed, or whatever you want for the 1st step*/
if autontime = 40 then /* this step happens for 40 loops */
begin
sequence = sequence + 1 /* next sequence next time */
autontime = 0 /*zero the loop count */
end
endif
else

if sequence = 1 then /*the next step*/
begin
right motor pwm = 0 /* turn hard right */
left motor pwm = 254
if autontime = 10 then /* this step happens for 10 loops */
begin
sequence = sequence + 1 /* next sequence next time */
autontime = 0 /*zero the loop count */
end
endif

else
if sequence = 2 then /* ect ect ect */

......

get the idea? have a variable that tells you which step of your sequence you are in, and have a variable that tells you how many times you have gone through the loop, and end that step when you have repeated it for a certain number of loops

this is dead rec - you have no outside info telling you how fast you are actually moving, how far you have turned - you have to use trial and error to test this with your bot and tweak the motor pwm settings for each sequence step, and tweak the autontime equality 'if' for each step, to get the bot to more or less go where you want it to go.

also, within each step you can turn other motors, or relays on and off, depending on what you want your machine to do at each step.

make any sense?

[Solace]

here's a hint - don't turn. just go in a straight line. the wall is your friend.

edit (I am completely serious)

[MisterX]

Thanks again for all your help again I defintatly have a better understanding know than when I originally posted this but could somebody have something in C code cause I am still not exactly sure how to write it, I now know what to say (before I wasn't all to sure.) Thanks all again for your help I'll definatyl remeber you guys for what you have done


P.S. Solace exactly how do you set it up to not turn in the style of this game?

[KenWittlief]

I think what solace is saying is, if you point your bot so it grazes the side barrier, then (depending on how your bot is powered, the type of drivetrain you have) the side rails will deflect it and it will skid along the railing, and be forced to go straight along the edge.

Im not sure how well that will work for all bots - if you have two wheel drive and castors or skids on the back, it might work

or your wheels might hit the side railing and stall, causing the bot to turn towards the railing, ending up square into it and going nowhere?

I dont know C programming well enough to translate what I wrote above into something that will compile, and even if I did, I would have to be there with you to test it on your bot and help you tweak it.

If you are going to have an auton mode, you are going to have to understand C a little bit - try looking over one or two control statement - like the IF statement - if you can get a good handle on how to use IF statements, you should be able to write the sequence algorythm somewhat like I explained it.

give it a shot - and something else - you cant always try your code with the wheels up off the ground, and see it its sorta doing what its suppose to, before you let the robot run by itself on the floor :c)

BTW - there are excellent resources on both the www.usfirst.org website for a tutorial on C, and the default code users guide in the document section of www.innovationfirst.com site.

[Xufer]

see when i read your post it popped into my head i wrote a counter and threw in some arbitrary numbers im just waiting to test it now, but thanks for the help, heres what i wrote.

if (rc_dig_in17) {
{
pwm01=200;                                /*Go forward for 2000*/
pwm02=200;
for(i = 0; i < 2000; ++ i);
pwm01=127;								  /*stop after*/
pwm02=127;
/*------------------------------------------------------------------------------*/
pwm01=127;                                /*Go right for 200*/
pwm02=200;
for(i = 0; i < 200; ++ i);
pwm01=127;								  /*stop after*/
pwm02=127;
/*-----------------------------------------------------------------------------*/
pwm01=200;                                /*Go forward for 200*/
pwm02=200;
for(i = 0; i < 2000; ++ i);
pwm01=127;								  /*stop after*/
pwm02=127;

}
}
/**********************************************DEADRECB*************************/
if (rc_dig_in16) {
{
pwm01=200;                                /*Go forward for 2000*/
pwm02=200;
for(i = 0; i < 2000; ++ i);
pwm01=127;								  /*stop after*/
pwm02=127;
/*------------------------------------------------------------------------------*/
pwm01=200;                                /*Go left for 200*/
pwm02=127;
for(i = 0; i < 200; ++ i);
pwm01=127;								  /*stop after*/
pwm02=127;
/*-----------------------------------------------------------------------------*/
pwm01=200;                                /*Go forward for 200*/
pwm02=200;
for(i = 0; i < 2000; ++ i);
pwm01=127;								  /*stop after*/
pwm02=127;

}
}

[KenWittlief]

you got the right idea, but you cant use the for loop- the uP will execute that code all at once, and only output the pwm values once

the entire code runs in one big loop

A. first the operator interface commands are read in (a serial input stream)

B. then the block of user code runs once (including your custom auton code)

C. then the pwm commands are sent out to the motors and relay spikes

D. goto A

this loop runs as long as the robot is on - and it takes about 26mS each time through

thats why I had that variable auton_time incrementing at the start of the auton code - everytime the loop runs that count goes up by 1, and you know another 26mS of your life has gone by.

so if I look for auton_time to be = 10, that means 260mS have gone by - about a quarter of a second. If I look for it to be 40, thats about a second.

so if you put a 'for' statement up there between B and C, it will sit and spin on itself very quickly, maybe 100 uS, and then go on like it wasnt even there.