counting in seconds for the autonomous mode??

hi there,

does any one knows how to convert the cycles of the autonomous mode 26.2ms to like actual seconds to keep a counter in seconds???

Thnx
Rockie team
help plz competition in 2 days :ahh: :ahh:

Here’s some code I wrote that we never used. Basicly, you follow the table and it shows you how many ticks or loops is equal to X number of seconds. You set the timer by calling auton_timer_1_start(), pass the number of ticks (loops) it should wait. In your code you can check if the time has passed by using something like this:


if (auton_timer_1()) {
     // Time has been reached
} else {
     // Still cycling, time has not been reached
}

Let me know if you don’t understand anything. Here’s the code:


// Start prototypes
unsigned char auton_timer_1();
void auton_timer_1_start(unsigned int time);
// End Prototypes

// Variables needed
unsigned int auton_timer_1_current = 0;	// Is updated every 26.2ms loop when using timer 1
unsigned int auton_timer_1_limit = 0;	// Is the time limit, which gets set by auton_timer_1_start()
// Done with variables

/* ################################ Start Timer Table ########################
			1s/26.2ms =~ 38 ticks/s
I.E: If you want a 1 second timer, you must set the timer for 38 ticks.
		-= Seconds =-	-= Ticks =-
		0.25			10
		0.50			19
		0.75			29
		1.00			38
		1.25			48
		1.50			57
		1.75			67								
		2.00			76	
		2.25			86
		2.50			95
		2.75			105
		3.00			115
		3.25			124
		3.50			134
		3.75			143
		4.00			153
		4.25			162
		4.50			172
		4.75			181
		5.00			191

 ############################### End Timer Table ################ */


/* ******************************************************************************
* FUNCTION NAME: auton_timer_1_start
* PURPOSE:       Set and start timer 1
* CALLED FROM:   anywhere
* ARGUMENTS:     time limit (unsigned int)
* RETURNS:       void
****************************************************************************** */

	void auton_timer_1_start(unsigned int time) {
		auton_timer_1_current = 0;
		auton_timer_1_limit = time;
	return;
	}



/* ******************************************************************************
* FUNCTION NAME: auton_timer_1
* PURPOSE:       Checks timer 1 to see if limit has been reached.
* CALLED FROM:   anywhere
* ARGUMENTS:     none
* RETURNS:       TRUE if limit has been reached, FALSE if time has not expired
****************************************************************************** */

	unsigned char auton_timer_1(void) {
		++auton_timer_1_current;
		if (auton_timer_1_current >= auton_timer_1_limit) {
			return 1;
		} else {
			return 0;
		}
	}

Here’s the simple solution I used to keep track of milliseconds.


#define MS *4
void User_Autonomous_Code(void)
{
	unsigned int clicks; /* 4000 clicks per second theoretical, 4007.63358779 clicks actual :-) */
	
	clicks = 0;
	
	while (autonomous_mode)   /* DO NOT CHANGE! */
	{
		if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
		{
			Getdata(&rxdata);   /* DO NOT DELETE, or you will be stuck here forever! */

			if (clicks < 16000 MS)
				clicks += 105; /* 26.2 more milliseconds have elapsed, this count will be fast by just over 0.19% */
			else
				clicks = 16000 MS; /* peg at 16 seconds */

			/* Add your own autonomous code here. */

			User_Mode_byte = clicks/400;
			Generate_Pwms(pwm13,pwm14,pwm15,pwm16);
			Putdata(&txdata);   /* DO NOT DELETE, or you will get no PWM outputs! */
		}
	}
}

I complicated things slightly by using four “clicks” per millisecond. In the normal case of autonomous operation, the unsigned int will not overflow, but I limited it to 16 seconds anyway. Defining MS as a modifier was just a convenience so the other programmer could use “real” times while deciding when the program should take action.

The User_Mode_byte on the OI counts in tenths of a second while the autonomous function is running.

First: Feel Free to Re-Organize IFI’s Autonomous Code

You may want to back up a little bit. Note that the only reason that loop is 26.2 ms is because of that Getdata. You only need to call Getdata when that statusflag.NEW_SPI_DATA flag gets set. Thus, if you organize your code well, you can run much faster cycles in autonomous mode. That may or may not be helpful to you.

Additionally, someone’s mentioned how you should put the Generate_Pwms in autonomous mode as well before the Putdata call. You might think about replacing the whole thing with Process_Data_From_Local_IO, and now that I think about it, you should probably put that P_D_F_L_IO outside the slow if( statusflag… ) block. That way you’ll be able to respond to robot sensors much more quickly in the exact same fashion as you respond to sensors in non-autonomous mode.

Don’t Use the 26.2 ms Cycles to Count Time

Now, that being the case, I would not recommend using the 26.2 ms flag for timing. If you wanted to, you could count down from 38, decrementing once a cycle, and every time you hit 0 you would have gone ABOUT 1 second. But there are better ways to doing things.

Use the PIC Counters to Keep Time for You (with Interrupts)

I’m fairly sure that the student who did most of the coding for the robot found instructions on IFI’s website on how to configure the counters to keep time for the robot. Right now, I can’t find where he found it, but I can show you the simple example in our own code:

http://www.osufirst.org/twiki/bin/view/OSUFIRST/DublinTeam2004RegionalCode

You’ll see that WE MUST INCLUDE timers.h. This is a SYSTEM INCLUDE, so you’ll have to include it with less-than and greater-than braces rather than quotes. After this, it’s fairly easy to configure a timer which produces an interrupt every 100th of a second (you can change this to faster or slower rates, but our code is configured for 100ths of a second).

Look at the interrupt handler in user_routes_fast.c. You’ll see that AT THE VERY BOTTOM OF IT, it increments an elapsedTime and also sets a timeUpdate. elapsedTime is our on-board “clock.” Every second, it sees an increment of 100. timeUpdate is a variable we use to communicate that a new “count” just occurred, letting some of our other routines do some “sampling.” That’s another story.

We also had to add code to the Initialize routine to configure the counter.

After all this, it was about 5 lines of code, and we could count on (no pun intended) elapsedTime keeping an “on-board clock” for us. I’d recommend doing something like this in your setup.

It makes sense to call Process_Data_From_Local_IO() inside the while loop but outside the if (statusflag.NEW_SPI_DATA) block. But you should not be calling Generate_Pwms() in the fast loop – the PIC PWM outputs get a little squirrely if you write to them too quickly.

hmmmm… I dont understand TedPs adversion to counting SW loops.

someone has tested the timing of the statusflag.NEW_SPI_DATA event- its controlled by a timer in the communications loop and testing has shown its dead accurate every time, unless you have so much code that it takes more than 26mS seconds to execute.

statusflag.NEW_SPI_DATA will be true 38 times a second - you can even round it off to 40 to make it simpler - I cant imagine anyone needing finer resolution that 1/38th of a second while setting up the sequence of events in auton mode ?

Time can be measured in seconds, or minutes, or hours, or microseconds. Why do you need to work in units of seconds? That conversion requires floating point arithmetic, and that means a lot of CPU time is used up. But how about using a new unit for time? Call it “ticks”. The conversion factor for seconds to ticks is

ticks = seconds * (10e6 / 2e18 );

The autonomous period lasts 572 ticks. The entire match is 4578 ticks.

You can keep track of ticks using integers and integer math, and avoid all that floating point stuff that takes up memory and CPU time.

BTW, I programmed my auton to take a swipe at the trigger ball starting at 534 ticks (38 ticks before the end of auton). It knocked off the ball, but the blue balls were not released. They claimed it was too late. It was our last match and the first time everything came together for IR tracking (i.e. we didn’t get rammed) Hmmm… At nationals I’m gonna back that down to 80 ticks before the end of auton.

when should we stop the robot, using a counter by following the line ???

is there any way of figuring that out/??? or is the only way just trying it on the robot and hoping it works ???

Here’s a very similar thread that may help you.

-norm

I tried to help you all I could. Now I’m at a loss trying to understand you. Please use complete sentances and proper punctuation. I spent about 10 minutes preparing an answer, please spend more than 1 minute answering.

Sorry for that… Thanks for your help. its just that i am really stressed about this and i feel i can’t handle it anymore :frowning:

ok here i go again

i think i have the code working for the line following with two sensors.

is there any way of knowing when to stop other than just timing it with like a stopwatch? to avoid the robot to hit the wall and be stuck to it ?

There’s 2 ways you can detect the end of travel:

  1. Your time and stop watch idea.
  2. You could install a microswitch (digital switch) and a bumper to the front of your robot. If you were following the line, and the bumper sensing switch was closed, you would know you hit the wall.

the competition is this thursday so i think we’ll have to do the stopwatch measure.

thnx people

For one, there’s no reason your autonomous mode code has to run at the slow rate. Only Getdata() when that flag goes high, and otherwise rattle around as fast as you can. You can Generate_Pwms() as fast as you can as well because those are the FAST PWMs. They can be handled specially. Additionally, Putdata() can be called as fast as you’d like. IFI specifically says that there is no harm done by calling Putdata() too fast; it also says that there’s not necessarily anything gained. It’s in the documentation.

Having interrupt-controlled timing that is triggered by an interrupt generated by the terminal count of a hardware timer timed fairly precisely to go off every 100th of a second (or even finer) seems much simpler than using a counter to do this timing. Additionally, you can use this counter later on in your competition mode code.

It just seems much cleaner to have an interrupt manage all your timing for you. You can get fairly fine time resolution, and you don’t have to worry about making sure you increment in time. Run code as slow as you’d like; the interrupt will jump in when it needs to increment your “clock.”

If you do things the more naive way, then you gain a second every twenty seconds, and you lose the ability to differentiate in time among a great number of cycles of your code. That may not be that big of a deal, but it definitely could use some improvement. Using the simple interrupt-driven timing does this. That’s all I’m saying.

See page 18 of:

http://www.innovationfirst.com/FIRSTRobotics/pdfs/2004_Programming_Reference_Guide_10-29-2003.pdf

on IFI’s website. In particular, you see that PutData() will handle PWMs 1-12, (slow PWMs) and those can only be changed every 26ms. While 13-16 are the fast PWMs that can be changed more often (every 2 ms).

IFI’s website is very clear that PutData and Generate_Pwms(13-16) can be called as quickly as possible, but G_Pwms is the only thing that generates those PWMs that quickly. It warns that devices connected to the PWM outputs may have trouble with the fast changing PWM outputs and to check those device specifications, but there’s nothing about the RC that makes this a bad idea.

After all, aren’t Putdata and Generate_Pwms called in the default fast routines anyway?

Well, we have had problems when using those generated PWMs, especially if they are called quickly. We’ve observed fluctuations in the motor we’re trying to adjust as well as induced outputs on other PWMs that are generated. Switching to PWMs 1-12 solved these problems.

While it may not be a bad idea in theory to call G_PWMs quickly, for practical application with the robots we are building, its unnecessary and possibly detrimental. Do you really need to update your actual motor output at faster than 38hz?

from TedP: Having interrupt-controlled timing that is triggered by an interrupt generated by the terminal count of a hardware timer timed fairly precisely to go off every 100th of a second (or even finer) *seems much simpler * than using a counter to do this timing…

setting up a hardware timer and writing an interrupt routine seems much simpler than putting


    **auton_time++; ** 

in your code

?!

you gotta remember lots of students are struggling just to understand this stuff, and dont normally use uP hardware everyday :^)

would this code work u think?? we’re going to use a stopwatch to determine how long it actually takes us in average. the only think we are doing in autonomous mod is driving to the 10 pt ball and hopefully noking it down.

void User_Autonomous_Code(void)
{
/* Initialize all PWMs and Relays when entering Autonomous mode, or else it
will be stuck with the last values mapped from the joysticks. Remember,
even when Disabled it is reading inputs from the Operator Interface.
*/
pwm01 = pwm02 = pwm03 = pwm04 = pwm05 = pwm06 = pwm07 = pwm08 = 127;
pwm09 = pwm10 = pwm11 = pwm12 = pwm13 = pwm14 = pwm15 = pwm16 = 127;
relay1_fwd = relay1_rev = relay2_fwd = relay2_rev = 0;
relay3_fwd = relay3_rev = relay4_fwd = relay4_rev = 0;
relay5_fwd = relay5_rev = relay6_fwd = relay6_rev = 0;
relay7_fwd = relay7_rev = relay8_fwd = relay8_rev = 0;

while (autonomous_mode) /* DO NOT CHANGE! /
{
if (statusflag.NEW_SPI_DATA) /
26.2ms loop area /
{
counter++;
Getdata(&rxdata); /
DO NOT DELETE, or you will be stuck here forever! */

    /* Add your own autonomous code here. */
    
    // counter calculated as (38*12)
    
			if ( counter &lt; 456 )  // still less than 12 seconds have elapsed
				{


	if (rc_dig_in01 == 0 && rc_dig_in02 == 0) 
    {
        pwm13 = pwm14=137;
        pwm15= pwm16=  137;
    }

    if (rc_dig_in01 == 1 && rc_dig_in02 ==0) 
    {
        pwm13 = pwm14= 128;
        pwm15= pwm16=  132;
    }

    if (rc_dig_in01 ==0 && rc_dig_in02 == 1) 
    {
        pwm13 = pwm14=132;
        pwm15= pwm16=128;
    }

   }


    Generate_Pwms(pwm13,pwm14,pwm15,pwm16);

    Putdata(&txdata);   /* DO NOT DELETE, or you will get no PWM outputs! */
}

}
}

Actually this is not true and is not a good idea to do blindly.
It isn’t a matter of how fast our controller can spit out PWM updates, but a matter of how fast the device at the receiving end is designed to be updated. The victor speed controllers are not designed for a 2ms update rate. I believe they update at 60Hz or 17ms.

Use the Generate_Pwms() at the slow-loop 26ms rate or create a separate timing loop to update them at 17ms minimum for fastest updates.

[edit] I double checked and the victor does at least one type of update at 60Hz, but IFI notes imply a faster PWM update rate. I haven’t been able to discover documentation on what that rate might be, other than 2ms is too fast.

You can make counter local to this routine. Nowhere else does it have to be seen.

I might add an initialization for counter, e.g.,


void User_Autonomous_Code(void)
{
unsigned int counter=0;
...
while (autonomous_mode) /* DO NOT CHANGE! */

[edit] The following is not germane to this case you should just be aware of the pitfall.
Even if you initialized counter when you declare it, e.g., static unsigned int counter=0; You’ll have trouble during the practice sessions when you run twice in a row. You’d have to be sure to reset the RC between runs. Explicitly setting it before the auto loop avoids this potential pitfall.

[edit]
Actually “static” isn’t required in this case, since you never leave the routine. I only tend to use it as a matter of convention (Our functions aren’t written to take control away from the main loop).
You can in this case declare “unsigned int counter=0;” in the local routine and be fine. I still prefer explicit initialization though.