[  3  /  a  /  adv  /  an  /  c  /  cgl  /  ck  /  cm  /  co  /  diy  /  fa  /  fit  /  g  /  i  /  ic  /  jp  /  k  /  lit  /  m  /  mlp  /  mu  /  n  /  o  /  p  /  po  /  q  /  sci  /  sp  /  tg  /  toy  /  trv  /  tv  /  v  /  vg  /  vp  /  w  /  wg  /  wsg  /  x  ]

/diy/ Do-It-Yourself

Warning: All the content of this page originally come from 4chan.org. This is only a partial archive made to avoid destruction. Some posts and images may be missing. All the messages below have been posted by anonymous users and we do not guarantee any truth of what they said.
For any illegal content, please contact me so that I can immediatly destroy it!

Anonymous 2015-09-24 02:38:08 No.879038

[Missing image file: ]

I have this flywheel, which is connected to a motor that I am controlling with a 127 to -127 resolution pwm controller. The flywheel is connected to a quadrature encoder with a 360 step (step?) per revolution resolution. With this, I am able to find the RPM of the flywheel. I need to get this flywheel to a specific speed and hold that speed. While open loop control (setting the pwm to an arbitrary value) is surprisingly good at this, I need to get to the speed faster and hold the speed more accurately. Thus, I wanted to implement a PID loop. While I think I could code a PID loop based on position, I am having difficulties coding a PID loop based on velocity, because once the motors get to the reach, there is no more error and they shut off, which means the flywheel never gets to the target velocity.

TL,DR; I need to code a PID loop that affects change in a value, not the value itself.

Below is what I have been using as a guide to PID:

Kp = ?
kI = ?
kD = ?
threshold = 150
Tp = 30
IntegralErr = lastErr = derivative = 0
prevTime = 0
Loop forever
{
Lightvalue = getcolorsensorval
currErr = Lightvalue – tVal
integral = integral + currErr
duration = RawTime - prevTime
derivative = (currErr – lastErr)/duration
lastError = currErr
prevTime = RawTime

Any help?
(Pic semi-related)


>>
Anonymous 2015-09-24 03:01:04 No.879051
velocity is the derivative of position
position is the integral of velocity

>>
Anonymous 2015-09-24 03:25:33 No.879069
>>879038

>(step?)

Encoders are classed based on pulses. You can usually get up to 4 counts per pulse out of this (with full quadrature encoding). If you mean 360ppr, that's 1440cpr. If you mean 360cpr, that's 90ppr.


Anyway...PID only sounds confusing if you take it at face value. Humans intuitively know how to do it, even if they don't necessarily know exactly how they're doing it.


It's simply reaching a value by adding three things:

1. The P term. This is simply the difference between your current speed and target speed. Using the P term alone tends to either result in oscillation, or never reaching target speed. Thus, we bring in...

2. The I term. The I term is the cumulative difference of the past readings. This is the key term in PID control. It's what allows a small but persistent error to accumulate into a response sufficient to eliminate it, and enables the controller to quickly close large errors where just a P control would taper off. It is, as in your example, simply the current error added to itself.

3. The D term. The D term is how fast the error is shrinking (or growing). Essentially, it's a refinement of the I term; the difference in the difference of past readings, if you will. This term isn't actually used that often, because PI control is typically sufficient, and the D term's impact on the stability of a system tends to be pretty variable in practical applications.

>>
Anonymous 2015-09-24 03:40:09 No.879083
>>879069

(con't.)

So, basically this means that your code should look something like:


get current_speed
current_error = current_speed - target_speed
P = current_error * x //where x is your P tuning parameter

i = i + current_error
i_t = i * x//where x is your i tuning parameter

PWM = P + i_t


After any scaling you might need to apply to get a value within your +/- 127, this should work on its own without a D term. If you want to add it, it looks pretty much the way it's written in your sample.

As far as tuning goes, note that an excessive P or I gain will cause oscillation, but too low will cause poor response. Too high a D gain will slow system response, while too low simply does nothing over having only PI control.

>>
Anonymous 2015-09-24 03:52:48 No.879088
>>879051
My knowledge of calculus is vague and conceptual at best, but I think I understand. Would that make acceleration the derivative of velocity?

>>879069
I got that (excellent explanation BTW), but does that mean the PID for position and velocity is the same, just with a velocity target rather than a position target and just with kP, kI and kD tuned different? or is there something else to make sure it maintains speed?

>>
Anonymous 2015-09-24 03:54:39 No.879089
>>879088
never mind, did not see>>879083

>>
Anonymous 2015-09-24 04:21:04 No.879106
>>879088
>Would that make acceleration the derivative of velocity?
Yep. Strictly speaking though, your system has angular position (angle), angular velocity, and angular acceleration.

>>
Anonymous 2015-09-24 04:51:27 No.879120
>>879088

For your application, position is completely irrelevant except where it's used to determine the current velocity. Once you've measured the current position, compared it to the last one, and determined how long it took you to go that far, you can forget about it.

Your speed is what you're trying to control, so that's all the PI(and maybe D) loop is concerned with.

>>
Anonymous 2015-09-24 05:08:56 No.879129
>>879083
Not OP...

Is there an IC that does that?

There are BLDC motor controller boards - e.g. http://www.lynxmotion.com/images/document/PDF/Lynxmotion%20-%20SimonK%20ESC%20-%20User%20Guide.pdf - that do speed control with a microcontroller. On a fundamental level, I don't like the idea of slaving additional microcontrollers to my microcontroller.

There are BLDC motor controller ICs - e.g. http://www.ti.com/lit/ds/symlink/drv11873.pdf - that take in a PWM, monitor hall effect sensors or current to measure the motor's phase, and output speed as a pulse, but it's my understanding that PWM is disproportional to speed when the motor is under load, so you still need to tweak the PWM.

>>
Anonymous 2015-09-24 06:24:20 No.879148
>>879129
>Is there an IC that does that?

Probably, although it's much more likely you'll find an IC that has such a thing implemented as part of its operation. Doing literally nothing but PID calculations would be a really weird thing for a standalone IC to do.

However, PI/PID control loops are extremely common in any system that needs accurate control of something, so there might be some weird-as-fuck chip out there that does almost nothing but that, IDK. Still, I find the idea unlikely, since I can't see anything using such a specialized chip when it would have to be cheaper to just use a general-purpose microcontroller. I suppose if you needed an obscenely high sample rate, maybe, but even then I would expect it to be more practical to use an FPGA or just, again, use a general-purpose microcontroller with feed-forward control to eliminate the need for high sample rate in the first place.


As far as I'm aware, few (if any) controls are meant to take real-time human input and use PID. Controlling pulse width directly seems to be the more intuitive and simpler/cheaper approach there. A fan controller like that TI chip might use it, but there's nothing mentioned about it in the datasheet, so the only way to know for sure would be to contact TI. (It probably doesn't, though.)

>>
Anonymous 2015-09-24 22:49:34 No.879499
>>879069
That seemed to work, now I just have to tune kP, kI, and kD. If I had three speed settings would the tuning parameters be different for different speeds?

>>
Anonymous 2015-09-24 23:03:02 No.879502
>>879499
no

>>
Anonymous 2015-09-24 23:32:50 No.879517
>>879499

No. If that were the case, PID would be much less useful. Tuning parameters are for getting the best response out of the system being controlled, without excessive overshoot or oscillation. What exactly you want the system to do doesn't matter.

>>
Anonymous 2015-09-25 01:29:38 No.879555
Op here. As long as no one has any tricks on how to tune a PID, I think I'm good. It's nice to know there is a place on the internet where people are still helpful. Anyway, to repay those who contributed for their time, I would be open to putting a worksafe decal of your choice on the machine. Thanks!

>>
Anonymous 2015-09-25 04:46:04 No.879614
>>879555
>Op here. As long as no one has any tricks on how to tune a PID, I think I'm good.

There actually are a few.

https://en.wikipedia.org/wiki/PID_controller#Overview_of_methods

Sounds like it'll be easiest to just do it manually, though.

>If the system must remain online, one tuning method is to first set K_i and K_d values to zero. Increase the K_p until the output of the loop oscillates, then the K_p should be set to approximately half of that value for a "quarter amplitude decay" type response. Then increase K_i until any offset is corrected in sufficient time for the process. However, too much K_i will cause instability. Finally, increase K_d, if required, until the loop is acceptably quick to reach its reference after a load disturbance. However, too much K_d will cause excessive response and overshoot. A fast PID loop tuning usually overshoots slightly to reach the setpoint more quickly; however, some systems cannot accept overshoot, in which case an over-damped closed-loop system is required, which will require a K_p setting significantly less than half that of the K_p setting that was causing oscillation.


Use the Anivia Sexbot logo (the name's an inside joke, don't worry about it; stick around DIY a few months and you'll probably see it). Appropriate, I feel, since that's actually what I was working on that required I learn what a PID loop was.

>>
Anonymous 2015-09-25 04:53:25 No.879617
>>879614
6-axis sexbot man?

>>
Anonymous 2015-09-25 05:02:54 No.879621
>>879617
>6-axis sexbot man?

Nope.

Although...now that I think about it, kind of a weird coincidence that both the actual robot-arm-sexbot and the "Anivia Sexbot" (again, not actually anything to do with a sexbot) both have six axes...

>>
Anonymous 2015-09-25 05:21:09 No.879627
>>879621
Well, thanks anyway. I will try and remember to create a thread to show off the logo when I finish.

>>
Anonymous 2015-09-25 05:22:52 No.879628
>>879627
*and the machine







[  3  /  a  /  adv  /  an  /  c  /  cgl  /  ck  /  cm  /  co  /  diy  /  fa  /  fit  /  g  /  i  /  ic  /  jp  /  k  /  lit  /  m  /  mlp  /  mu  /  n  /  o  /  p  /  po  /  q  /  sci  /  sp  /  tg  /  toy  /  trv  /  tv  /  v  /  vg  /  vp  /  w  /  wg  /  wsg  /  x  ]

Contact me | All the content on this website come from 4chan.org. All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.

Dofus quêtes

Page loaded in 0.003696 seconds.