|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
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 ![]() |
|
#2
|
|||||
|
|||||
|
Re: counting in seconds for the autonomous mode??
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:
Code:
if (auton_timer_1()) {
// Time has been reached
} else {
// Still cycling, time has not been reached
}
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;
}
}
Last edited by MikeDubreuil : 30-03-2004 at 16:34. |
|
#3
|
|||||
|
|||||
|
Re: counting in seconds for the autonomous mode??
Quote:
Code:
#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! */
}
}
}
The User_Mode_byte on the OI counts in tenths of a second while the autonomous function is running. |
|
#4
|
|||
|
|||
|
Re: counting in seconds for the autonomous mode??
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/vi...04RegionalCode 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. |
|
#5
|
|||||
|
|||||
|
Re: counting in seconds for the autonomous mode??
Quote:
|
|
#6
|
||||
|
||||
|
Re: counting in seconds for the autonomous mode??
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 ? |
|
#7
|
|||||
|
|||||
|
Re: counting in seconds for the autonomous mode??
Quote:
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. |
|
#8
|
|||
|
|||
|
Re: counting in seconds for the autonomous mode??
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 ??? |
|
#9
|
|||||
|
|||||
|
Re: counting in seconds for the autonomous mode??
Quote:
-norm |
|
#10
|
|||||
|
|||||
|
Re: counting in seconds for the autonomous mode??
Quote:
|
|
#11
|
|||
|
|||
|
Re: counting in seconds for the autonomous mode??
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
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 ? |
|
#12
|
|||||
|
|||||
|
Re: counting in seconds for the autonomous mode??
Quote:
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. |
|
#13
|
|||
|
|||
|
Re: counting in seconds for the autonomous mode??
the competition is this thursday so i think we'll have to do the stopwatch measure.
thnx people |
|
#14
|
|||
|
|||
|
Re: counting in seconds for the autonomous mode??
Quote:
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. |
|
#15
|
|||
|
|||
|
Re: counting in seconds for the autonomous mode??
Quote:
http://www.innovationfirst.com/FIRST...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? |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Future of Autonomous Mode | FadyS. | Programming | 41 | 24-05-2004 19:45 |
| Simple Autonomous Mode Example | deltacoder1020 | Programming | 5 | 08-03-2004 20:22 |
| Initializing autonomous mode | Mr. Lim | Programming | 7 | 02-02-2004 07:26 |
| autonomous mode problem on field | Chris_C | Programming | 17 | 26-03-2003 19:11 |
| autonomous mode timer | Don | Programming | 6 | 09-02-2003 22:16 |