Chief Delphi - problem with autonomous that has stumped all programmers so far

Page 1 of 3

Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - problem with autonomous that has stumped all programmers so far (http://www.chiefdelphi.com/forums/showthread.php?t=26557)

bd02	08-03-2004 19:04

problem with autonomous that has stumped all programmers so far

1 Attachment(s)

The autonomous mode i programmed for our robot for dead wreckoning was working fine. It would count the # of 26.2 ms and use them to time the movements of the bot. The first time i setup the code with sample times it worked just fine, but once i put actual times in that we received from out test runs, the cpu seemed to skip the first few steps and and go directly to the area where the robot is todl to move forward for 3 seconds. I asked a group of programmers at the Regional in Trenton, which were mostly coaches or people with enough knowledge of the language to comprehend my code, and they all said my code was written fine and should be working ok. I myself do web programming the usual html (even though it isn't really considered a language), vbscript, javascript, asp, sql, and php, and have had no real trouble in the past with debugging, but now I'm just stuck. Can anyone help me with this? :confused:

Attatched is my working code. Whenever i changed the time values for each state or change SECS_TO_TICKS to MSECS_TO_TICKS, it throws it off for some reason and makes it skip states. Any ideas?

jacob_dilles

08-03-2004 19:13

Re: problem with autonomous that has stumped all programmers so far

we orignaly had an atonomus code that looke strikingly similar to yours and had a very similar problem, we could not resolve it. after 2 days of total frustration, i compleatly re-wrote the code using 6 big if statements and a simple counter. from then on it worked perfectly. i think that there might be an issue with how the compiler disassembles complex switch statements. i hope you can get it working!

bd02	08-03-2004 19:20

Re: problem with autonomous that has stumped all programmers so far

I'll have to try that. It actually seems more practical than these huge cases. The reason the code might look so familiar is because it is based on a few lines of code I found here on the Delphi forums.

jacob_dilles

08-03-2004 19:22

Re: problem with autonomous that has stumped all programmers so far

what i did... if youll hold on ill get you the actual code... is not actualy a timer but a inturupt on a wheel counter. this however can be used exactly like a timer except it is not speed dependent ( i.e. you can change speed without haveing to wory about distance ). stand by

KenWittlief

08-03-2004 19:26

Re: problem with autonomous that has stumped all programmers so far

My first guess would be that the variables used in auton mode, ie tick count or the states... are not being cleared when auton mode is not running - it should be done at the end of your driver mode code, so that whenever the bot is switched into (back into?) auton mode, it starts from the beginning.

bd02	08-03-2004 19:29

Re: problem with autonomous that has stumped all programmers so far

Quote:

Originally Posted by KenWittlief

Auton mode is only activated once every round, and pressing reset on the FRC before or after a round automatically clears these values for us.

KenWittlief

08-03-2004 19:30

Re: problem with autonomous that has stumped all programmers so far

I just checked again

tick_count is cleared to 0 when your auton code is first called, but AUTO_STATE is not set to the first state.

bd02	08-03-2004 19:31

Re: problem with autonomous that has stumped all programmers so far

Quote:

Originally Posted by KenWittlief

I just checked again

tick_count is cleared to 0 when your auton code is first called, but AUTO_STATE is not set to the first state.

It's set to the first state in the auton mode variables up top

KenWittlief

08-03-2004 19:34

Re: problem with autonomous that has stumped all programmers so far

reset does not clear your variables unless you have then specified with a init value somewhere else in the code, where they are declared or in the initialization section.

but either way, you should be able to switch back and forth between auton and driver mode without someone having to push a reset button - just have a section at the end of your driver mode code that sets up the auton variables to start from the beginning - it will make testing your bot much easier.

BTW - when the bot is disabled it is in normal(driver) mode - the pwm outputs are disabled but that code is still running - when they do auton mode they enable it for a cycle or two, then they switch to auton mode.

jacob_dilles

08-03-2004 19:36

Re: problem with autonomous that has stumped all programmers so far

this is the meat of my code... as you can guess the drive motors are on pwms 15,16 and the inturpts incrment count.

Code:

/********************************************************

************jacobs autonoumus code....******************** 

*******************************************************/

                  relay8_fwd = !rc_dig_in18;                          // Power pump only if pressure switch is on. 

                  relay8_rev = 0;

//this start start it moving... ladies and gents start your engins

                if(count >= 0 && count < 2) {

                         pwm15 = 127 + 50;                        //drive strait

                        pwm16 = 127 + 50;                        //drive strait

//turn to get the ball

        if(count> 12 && count < 14) {

                foward = 0;                                        //turn off correction algoritiom (cuz were turning duh)

                         pwm15 = 127 + 50;                        //make right wheel turn fowards

                        pwm16 = 127 - 50;                        //make left wheel turn backwards

                        pwm01 = 254;                                //make arm go up

                }

                if(rc_dig_in16 == 1) {                                 //make sure arm doesnt go to high!!!

                        pwm01 = 127;

                }

//then we have to go strait slightly to get to the ball

                if(count > 14 && count < 16) {

                         pwm15 = 127 + 50;                        //go foward

                        pwm16 = 127 + 50;                        //go foward

                        relay3_fwd = 1;                                //open the gripers...

                        relay3_rev = 0;                                //open the grpiers...

                }

//now turn to AND close the gippers to knock/grab ball off... combo move HI-YAH

                if(count > 18 && count < 23) {

                         pwm15 = 127 - 50;                        //turn the other way

                        pwm16 = 127 + 50;                        //turn the other way

                        relay3_fwd = 0;                                //close grippers

                        relay3_rev = 1;                                //close grippers

                        

                }



//NOW we shut down motors

        if(count > 24 && count < 100) {

                 pwm15 = 127;                                        //turn the other way

                pwm16 = 127;                                        //turn the other way

                }        

/***********************************************************

*******************end jacobs auton code****************** 

***********************************************************/

bd02	08-03-2004 19:37

Re: problem with autonomous that has stumped all programmers so far

I noticed the prob with the vars not returning to their original values when i first modified the code, so i couldn't run it again once i had already ran it, but once i pressed the reset button it would run it perfectly as though i had never ran it before, so i just figured it cleared my values to the original state

jacob_dilles

08-03-2004 19:39

Re: problem with autonomous that has stumped all programmers so far

Quote:

Originally Posted by KenWittlief

but either way, you should be able to switch back and forth between auton and driver mode without someone having to push a reset button - just have a section at the end of your driver mode code that sets up the auton variables to start from the beginning - it will make testing your bot much easier.

in the begening of the auton mode code you should have a:

Code:

unsigned count = 0;

unsigend leftcount = 0;

unsigned rightcount = 0;

so that you dont have to reset. it is a matter of pricaple. this way you will never get thos errors

bd02	08-03-2004 19:45

Re: problem with autonomous that has stumped all programmers so far

I'll try it out and let you know how it works out. I just found out my team is totally redesigning the electronics board, so that complicates things a bit for me, but i'll let you know in a few days or so what's goin' on.

KenWittlief

08-03-2004 19:48

Re: problem with autonomous that has stumped all programmers so far

if the only thing you changed was adding this stuff:

SECS_TO_TICKS(a) ( ((int)(a)) * 10000 / 262 )

then maybe its not doing what you think it is?

int is signed, isnt it? so if a = 4 you end up with 40,000 which is a negative number divide by 262?

if this is what you changed and it got weird on you, just work with the tick counts in your code forget the fancy translations.

also could try running with a few printf statements and see what is happening at the start and end of each state - there might be something weird going on.

deltacoder1020

08-03-2004 20:09

Re: problem with autonomous that has stumped all programmers so far

Quote:

Originally Posted by KenWittlief

int is signed, isnt it? so if a = 4 you end up with 40,000 which is a negative number divide by 262?

if this is what you changed and it got weird on you, just work with the tick counts in your code forget the fancy translations.

also could try running with a few printf statements and see what is happening at the start and end of each state - there might be something weird going on.

nice catch, Ken. the code this is based off of is an example that I posted on the forums here: http://www.chiefdelphi.com/forums/sh...d.php?p=233912

the problem is that for any time period larger than about 3 seconds, 10000*a is greater than the max limit for a plain "int", and thus it's either wrapping around or just mucking stuff up.

you can solve this problem by changing the declarations of SECS_TO_TICKS and MSECS_TO_TICKS to the following, which use a "long" instead of an "int" (you'll notice that tickCount is already defined as a "long"... at least I was thinking clearly there! :)):

Code:

//A handy-dandy macro to convert a number of seconds into a number of 26.2ms ticks

#define SECS_TO_TICKS(a)        ( ((long)(a)) * (long)10000 / (long)262 )

//And milliseconds too:

#define MSECS_TO_TICKS(a)        ( ((long)(a)) * (long)10 / (long)262 )

weee... can never have enough type casts.

I remember when I originally typed in the code, i for some reason was thinking that seconds would only need to be multiplied by 1000 - I realized my mistake, but forgot that by changing it to 10000 i needed to increase the type of integer for which that math was done.

So for anyone using the example I posted here, that change should fix it quite nicely. :)

Nice to see my examples are being used and are helpful for some teams.

All times are GMT -5. The time now is 11:09.

Page 1 of 3

Show 100 post(s) from this thread on one page