Hi
Recently our team has been struggling through our autonomous program by using some trial and error and hoping that we could get it to work. Unfortunatly we have hit a problem that is timming loops. I ran a search for timing loops on this site and found some info but have been unable to adapt it or even figure it out.
I was wondering if some of you briliant programs could write a simple segment for our autonomous program. I would like to have PWM 1 to have a value of 254 or whatever “full forward” is when the program starts and have it run for .5 seconds at that speed then stop.
It would be handy if you could explain what values would need to be changed in order to adjust the length of time the motor is on and how fast it goes.
I greatly appreciate your help in this matter. Thank you.
one way you could accomplish timing is using the basic controller’s constant speed, the controller runs at about 38 Hz (38 times a second). if you wanted to count time you could have something like Time = Time + 1 + delta_t. Time would be the times the program has looped through, you add one to make it one more time and add delta_t in case the program “reset” because it took too long to respond (delta_t is the amount of packets missed) some syntax for the control could be
Time = Time + 1 + delta_t
if Time < 19 then 'counts to about 1/2 second
p1_y = 254
p3_y = 254
endif
if Time > 19 then 'after 1/2 second robot stops
p1_y = 127
p3_y = 127
endif
if you want 1 second you could replace 19 with 38, because 38 cycles is approx. 1 second, use greater than and less than symbols because it’ll do that action during that time period and also in case the program happens to miss that exact cycle it won’t skip that phase of your code
you would also have to define your variables, you don’t have to use time, that’s just something that i picked, you may also have to “define” (take out the comment in front of delta_t) and also set change c_delta_t CON 0 to c_delta_t CON 1 and include it in the serin line (look at the example above it for the correct placement in the line)
i thought the controller looped the code once every 26 milliseconds? so you would make a little counting function in the main loop, and assume that for each additional value of the counter the program has run for another 26 milliseconds?
yes that is correct, the controller does loop every 26 milliseconds, which comes out to 38.46153846 times per second. that is why i use 38 as my approximation for 1 second. and yes, every 26 milliseconds my counter value would increase by one
Also, make sure the initialized inputs that are turned on ie
c_p3_trig CON 1
is the same as the number of things in the SERIN.
My word, we spent hours figuring this out.
Please don’t yell at me if I used some wrong terminology.
*Originally posted by Lord Nerdlinger *
**i thought the controller looped the code once every 26 milliseconds? so you would make a little counting function in the main loop, and assume that for each additional value of the counter the program has run for another 26 milliseconds? **
Count loops if you like, but there is no guarantee that it will work - if there is a problem, you may skip a loop or two, and thro timing way off.
It is recommended that the count-up-delta_t method, or the change in packet_num be used, as they don’t skip. Every 26 ms, the Operator Interface sends a new packet of instructions, and each packet has a serial number, the packet_num. The Robot Controiler stores the packet_number for its own purposes, and reports it to you via the serin statement in your prohram if you select it.
The RC also calculates the differrence between the current packet_num and the last one it stored, and will similarly pass this info on to your program.
If your program starts to take too long in the loop when you add the last code, delta_t may rise to 2 even 3 (packets / time periods have been missed. Don’t @#@#@# U ME it makes an @#@#@# out of you & me
the way the program could skip a loop is if, for some reason, the rc doesn’t send a response soon enough (26 milliseconds) then it’ll restart w/ the serin command and the program stores the number of skipped loops into delta_t (resets back to 0 every time the program is fully looped through) (i think of delta_t as delta meaning change or difference in and t as time, or the difference of time since last loop went through)
Alright all you smark people, pay attention. Whilst programming my team’s robot, my mentor and I discovered sometheing rather unexpected: Our robot’s autonoymous timing was solely dependent on the number of Debug statements we had entered into our program. :rolleyes:
Trust me, we laughed at that. We initially had placed debug statements into our program to help us figure out exactlywhat all we were doing. When we decided removed a debug statement, the time was drastically shorter. The thing is, we only had three debugs entered!
My point is, if worse comes to worse, perhapse you could try and add some debug statements to your code and see what happens, though I don’t recommend it.
*Originally posted by whickedmoo * … timing was solely dependent on the number of Debug statements we had entered into our program. :rolleyes:…
While Debug statements are very useful, they should never be left in while running your “competition intent” code. As you’ve noticed, they slow down the overall process. This can make a big difference with timing loops and especially closed loop feedback.
Use the debug commands to troubleshoot the logic of your program, but then comment them out with the delimiter (') when you want the experience the overall effect of the “real” program.
*Originally posted by whickedmoo *
**My point is, if worse comes to worse, perhapse you could try and add some debug statements to your code and see what happens, though I don’t recommend it. **
debug statements are SLOW. They send data serially through the programming port at 9600 bps = 1200 bytes/sec. since there are 38 packets a second, you can send at the most 31 bytes. Since you do a lot of other stuff in your program, it’s really much less. If you have too many, you will skip loops.
If you incremented your counter by 1+delta_t, the debug statements would have far less of an impact, however, it would still be affected because you wouldn’t have the same resolution.
Here’s an idea for everyone that I really like using for our code: use the conditional compilation statements (only availible in the BETA compiler for PBasic 2.5)… so:
That way if you have multiple debug statements you dont have to search your code for all of them, just comment out the #define and the debugs wont compile.
*Originally posted by randomperson *
**Here’s an idea for everyone that I really like using for our code: use the conditional compilation statements (only availible in the BETA compiler for PBasic 2.5)… so:
#define showdebug
…**
Does this work? I thought I had tried it (with no success.) And Parallax’s web site still says:
A newer version is expected to be released in the next few weeks which will include the following additional features:
Color syntax highlighting which makes editing and debugging PBASIC programs much easier
Integrated online help file with new PBASIC command examples
Conditional compilation directives
a) it works in my code…
b) the alpha version FIRST released for useage by FIRST teams mentioned the compilation directives in the release notes for that version… and apparently they have it in the beta version as well except they didn’t document it…
Some things to remember… all the statements have to have a # before them otherwise they are treated as regular code. So:
