Go Down

Topic: Arduino PID Library (Read 59 times) previous topic - next topic

mem

#20
Jan 15, 2009, 04:44 pm Last Edit: Jan 15, 2009, 04:44 pm by mem Reason: 1
br3ttb, no need to be modest ;)

I did some minor editing to the font sizes to make the page a little easier to read, hope you don't mind.

Mike Mc

Ahh glad it wasn't me being dumb then ;)

Nice to see it up there for all to see :)

EvilSpeeder

Here's another vote for the int version.  

I'm currently trying to use your library to control motor speeds for a robot.  I haven't gotten everything working correctly yet, but I'm concerned that the arduino will not be able to run the methods in this library and still process interrupts at the required frequency (as high as 1700kHz)?  How is this done on and industrial motor controller?  Do they do the PID math on the physical motor controller, or is it done elsewhere on a main processor?

br3ttb

I want to make sure we're on the same page here.  for simplicity's sake, I set up the library so you call .Compute() every cycle.  most of the time, the library says "I don't need to recalculate yet" and immediately spits back to the calling routine.  the recalculation happens at 1Hz by default, but can be adjusted to be slower or faster using the SetCalcFrequency function.

so most of the time Compute() kicks back "instantly."  I don't think there's an interrupt problem there.  however, on the cycles where recalculation is occurring I think there may be. I did some bench tests before I published the library the calc speed was about 12 microseconds (8.3kHz.)  so it may be possible, if the interrupt pulse is faster than that, and it comes while the pid is calculating, the signal may be missed.

I have no idea how this is done in motor controllers.  my experience is on slower moving stuff, and as a consequence it's not a problem for the pid to be "slow" as well.

I am currently working on an integer version of the library (and the crowd goes wild.)  it's not going to be anywhere as feature rich as the "full" version, but hopefully it will be much, much faster.  

Brett

EvilSpeeder

That's kinda what I was thinking but this clarifies it much more.  I think you may right about the possibility of missing pulses while in a calculation but that's one of the many pitfalls of dead-reckoning navigation.  However, I don't think it's going to be a big problem because I think my overall error from other factors will outweigh the lost counts here and there.  It sounds like your 'full' library may work but I bet the 'lite/int' version would work a lot better!!   ;)

Thanks, this has been a big help to me!

Go Up