![]() |
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: |
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()) {Code:
// Start prototypes |
Re: counting in seconds for the autonomous mode??
Quote:
Code:
#define MS *4The User_Mode_byte on the OI counts in tenths of a second while the autonomous function is running. |
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. |
Re: counting in seconds for the autonomous mode??
Quote:
|
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 ? |
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. |
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 ??? |
Re: counting in seconds for the autonomous mode??
Quote:
-norm |
Re: counting in seconds for the autonomous mode??
Quote:
|
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 ? |
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. |
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 |
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. |
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? |
Re: counting in seconds for the autonomous mode??
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? |
Re: counting in seconds for the autonomous mode??
Quote:
Code:
auton_time++; ?! you gotta remember lots of students are struggling just to understand this stuff, and dont normally use uP hardware everyday :^) |
Re: counting in seconds for the autonomous mode??
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 < 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! */ } } } |
Re: counting in seconds for the autonomous mode??
Quote:
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. |
Re: counting in seconds for the autonomous mode??
Quote:
I might add an initialization for counter, e.g., Code:
void User_Autonomous_Code(void)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. |
Re: counting in seconds for the autonomous mode??
Quote:
BTW at most regionals they have a carpet setup in a back hallway where you can test your auton code - you usually have to sign up for a time slot, but it really helps to be able to test it, tweak your code, test it again... it looks good - your on the right path. |
Re: counting in seconds for the autonomous mode??
Quote:
Quote:
|
Re: counting in seconds for the autonomous mode??
Regarding pwm13-16: See this thread, and see Kevin Watson's FAQ especially the first really long question.
I stay away from PWM13-16. 38 Hz is fast enough for me! |
| All times are GMT -5. The time now is 20:59. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi