Solution to Timing Loops

[Rickertsen2]

prolly a dumb question, but why do you add in delta_t?

[edit]
o wait nevermind.
but how often does the other processor send packets to the stamp?

what about packetnum? what does that do?

[Greg McCoy]

Originally posted by Rickertsen2
prolly a dumb question, but why do you add in delta_t?

This is what I've been wondering the whole time. "Solution to timing loops"? I didn't know there was a problem, lol...

[rbayer]

Originally posted by Greg McCoy
This is what I've been wondering the whole time. "Solution to timing loops"? I didn't know there was a problem, lol...

Using delta_t gives you a more accurate reading of how much time has passed. The problem revolves around the fact that loop speed on the IFI controller is quantized and is always a multiple of 26ms. Therefore, if your code takes 27ms to get through a loop, you're actually going to run as 52ms per loop because you have to wait for the next one.

Using delta_t, you can determine if you missed any 26ms intervals between serins, so you would actually know that 52ms has passed in the previous example instead of "one loop" which could be either 26 or 52ms.

--Rob

[Greg McCoy]

Ok, that makes sense, but does 26 some milliseconds in drive time really affect the robot as it drives? I ran automated code without this and had almost perfect position accuracy. It seems like an awfully tiny difference to me.

[Steven Carmain]

Greg, quit screwing up my posts and work on wiring our second drive base, our anti-gravity one. I need the electrical done so I can do the program.

[Joe Ross]

Originally posted by Greg McCoy
Ok, that makes sense, but does 26 some milliseconds in drive time really affect the robot as it drives? I ran automated code without this and had almost perfect position accuracy. It seems like an awfully tiny difference to me.

It will make no absolutely no difference if the time through the longest set of branches in your code is less then 26 ms. It will make a slight difference if the the occasional loop is more then 26 ms. If each loop takes 120ms, and you assume 26ms per loop and don't use delta_t, you are in big trouble.

[Greg McCoy]

Originally posted by Steven Carmain
Greg, quit screwing up my posts and work on wiring our second drive base, our anti-gravity one. I need the electrical done so I can do the program.

My intention is not to "screw up posts" or anything of the like, but only to help everyone make better code and solve robot problems. We ALL can learn something new. Discussing topics like this is most certainly helpful to countless teams, both those with a lot of programming experience and those that don't quite have so much skill or knowledge. Sorry if I offended anyone or their ideas...

[Rickertsen2]

adding delta_t won't make any difference in your code unless your loop takes more than 26ms.

does anybody know what packet_num does?

[randomperson]

Blah...

I keep seeing posts on timer this, timer that.. why use software timers? So inaccurate if you have lots of code.. I mean, the loop isn't always a set period of time if you mod the code a lot (yeah, we aren't really using anything in the default code except the declarations.. and most of those are gone too.. lol). Using a hardware pulse generator (555 anyone?) allows you to have multiple software timers without worrying too much about loop periods and other useless complex crapola. I mean, you only need a resolution of around 1/4 second at most anyways..

[Steven Carmain]

Originally posted by randomperson
So inaccurate if you have lots of code.. I mean, the loop isn't always a set period of time if you mod the code a lot (yeah, we aren't really using anything in the default code except the declarations.. and most of those are gone too.. lol).

That is the purpose of delta_t. It always runs and sees how many loops you missed, if any. And I found out it can be a nib insted of a byte to save on variables. Now, if D.J. and Greg finish wiring the drive base...