Arduino-PID-Library
Arduino-PID-Library copied to clipboard
br3ttb
Erratic behavior when using external AREF
I LOVE your PID library and the thorough explanation! Thank you.
I've been using it to control a small robotic arm and just ran into a random problem. I'm doing some current sensing along with driving the robot, and just recently tried to connect Arduino's AREF pin to 3.3V to get higher resolution. In order to do this, I need this line of code in the setup():
analogReference(EXTERNAL);
The weird thing is that although this should be completely separate from the PID loop and rest of the code, when I insert this line, the robotic arm joint angles get messed up and the behavior is erratic. If I use the exact same code and hardware setup, but comment out the above line, it works fine! Any thoughts on why this might be? It's a VERY weird, illogical error as far as I can tell. Thanks in advance!
Is your 3.3V reference erratic or stable? Are you properly grounded with the 3.3V signal? That could cause fluctuation in your input and therefore your output.
Yeah the 3.3V ref is stable, it's the one on the actual Arduino board. I checked it with my multimeter and it stays pretty solid at 3.294V. Either way, and erratic AREF for a sensor shouldn't impact the robotic arm positioning at all - the current sensing that uses AREF is not in any kind of feedback loop with the control.
glad you like the library! (except for right now)
other than millis(); the pid library is just doing straight math. this sounds like a Garbage-In Garbage-Out kind of situation. it might be worth a few Serial.println() statments to see how the value of Input behaves in the different modes. (those print statements will also work within the library code as well I believe, if you really feel like it's something internal to the library)
back to the millis() thing, maybe the EXTERNAL mode causes it to behave erratically (unlikely) or maybe it causes analogReads to take longer (more likely?) leading to the algorithm to be evaluated irregularly. other than a scenario where internal PID variables are somehow being overwritten from the outside, this is the only thing I can think of that would point to the issue being inside the library.
my money is on altered input quality.
On Thu, Jan 9, 2014 at 7:31 PM, Dustyn [email protected] wrote:
Yeah the 3.3V ref is stable, it's the one on the actual Arduino board. I checked it with my multimeter and it stays pretty solid at 3.294V. Either way, and erratic AREF for a sensor shouldn't impact the robotic arm positioning at all - the current sensing that uses AREF is not in any kind of feedback loop with the control.
— Reply to this email directly or view it on GitHubhttps://github.com/br3ttb/Arduino-PID-Library/issues/13#issuecomment-31992433 .
Brett
Hmm thanks for the input, I'll try that when I'm back in the lab Monday. I can't find anything online about the external AREF altering input quality, most posts about using the 3.3V ref with sensors say the opposite - more stable, better resolution, etc. So freaking weird.
And seriously - if I ever teach a controls course, I'm using your post! It's an amazing example of how theory in general varies quite a bit from real world implementation. Thank you for taking the time to share that and do such a good job.
On Fri, Jan 10, 2014 at 7:55 AM, br3ttb [email protected] wrote:
glad you like the library! (except for right now)
other than millis(); the pid library is just doing straight math. this sounds like a Garbage-In Garbage-Out kind of situation. it might be worth a few Serial.println() statments to see how the value of Input behaves in the different modes. (those print statements will also work within the library code as well I believe, if you really feel like it's something internal to the library)
back to the millis() thing, maybe the EXTERNAL mode causes it to behave erratically (unlikely) or maybe it causes analogReads to take longer (more likely?) leading to the algorithm to be evaluated irregularly. other than a scenario where internal PID variables are somehow being overwritten from the outside, this is the only thing I can think of that would point to the issue being inside the library.
my money is on altered input quality.
On Thu, Jan 9, 2014 at 7:31 PM, Dustyn [email protected] wrote:
Yeah the 3.3V ref is stable, it's the one on the actual Arduino board. I checked it with my multimeter and it stays pretty solid at 3.294V. Either way, and erratic AREF for a sensor shouldn't impact the robotic arm positioning at all - the current sensing that uses AREF is not in any kind of feedback loop with the control.
— Reply to this email directly or view it on GitHub< https://github.com/br3ttb/Arduino-PID-Library/issues/13#issuecomment-31992433>
.
Brett
— Reply to this email directly or view it on GitHubhttps://github.com/br3ttb/Arduino-PID-Library/issues/13#issuecomment-32025014 .
if you ever teach a controls course, be sure to take a look at MY controls professor's stuff: http://controlguru.com
(sure worked for me)
On Fri, Jan 10, 2014 at 10:13 AM, Dustyn [email protected] wrote:
Hmm thanks for the input, I'll try that when I'm back in the lab Monday. I can't find anything online about the external AREF altering input quality, most posts about using the 3.3V ref with sensors say the opposite - more stable, better resolution, etc. So freaking weird.
And seriously - if I ever teach a controls course, I'm using your post! It's an amazing example of how theory in general varies quite a bit from real world implementation. Thank you for taking the time to share that and do such a good job.
Dustyn Roberts, PE, PhD Candidate -- NSF Graduate Research Fellow, NYU School of Engineeringhttp://engineering.nyu.edu/ -- Adjunct Professor, NYU ITP http://itp.nyu.edu/itp/ -- 201-452-1583 | LinkedIn http://www.linkedin.com/in/dustynroberts/
On Fri, Jan 10, 2014 at 7:55 AM, br3ttb [email protected] wrote:
glad you like the library! (except for right now)
other than millis(); the pid library is just doing straight math. this sounds like a Garbage-In Garbage-Out kind of situation. it might be worth a few Serial.println() statments to see how the value of Input behaves in the different modes. (those print statements will also work within the library code as well I believe, if you really feel like it's something internal to the library)
back to the millis() thing, maybe the EXTERNAL mode causes it to behave erratically (unlikely) or maybe it causes analogReads to take longer (more likely?) leading to the algorithm to be evaluated irregularly. other than a scenario where internal PID variables are somehow being overwritten from the outside, this is the only thing I can think of that would point to the issue being inside the library.
my money is on altered input quality.
On Thu, Jan 9, 2014 at 7:31 PM, Dustyn [email protected] wrote:
Yeah the 3.3V ref is stable, it's the one on the actual Arduino board. I checked it with my multimeter and it stays pretty solid at 3.294V. Either way, and erratic AREF for a sensor shouldn't impact the robotic arm positioning at all - the current sensing that uses AREF is not in any kind of feedback loop with the control.
— Reply to this email directly or view it on GitHub<
https://github.com/br3ttb/Arduino-PID-Library/issues/13#issuecomment-31992433>
.
Brett
— Reply to this email directly or view it on GitHub< https://github.com/br3ttb/Arduino-PID-Library/issues/13#issuecomment-32025014>
.
— Reply to this email directly or view it on GitHubhttps://github.com/br3ttb/Arduino-PID-Library/issues/13#issuecomment-32035012 .
Brett
With potentiometers. This is an Instructable on an older version of the project: http://www.instructables.com/id/Robotic-Arm-with-Servo-Motors/
Well you only need to do that if you are switching between External and Internal reference I guess. Definitely debug out the position in a println. Is your motor decently isolated electrically speaking?
I always find Pololu's advice on motor noise to be helpful:
http://www.pololu.com/docs/0J15/9
Yup, that's what I read. I might do that anyway with a similar size resistor since I don't need the full 3.3V range anyway. The motor and logic power supplies are separate, so it's isolated, but as you can see in the Instructable the cable isn't shielded or anything. There are caps inside each motor housing soldered to the terminals. But any weird noise isolation issues would be systemic anyway, not only occurring when I switch AREFs (one would like to assume).