Yeah, one thought just popped out of the mental delay line.......
For positioning (at least in an open frame assembly), consider a ping module for vertical position (and one for horizontal positioning if two axis of control). Use the ping to measure the actual distance from ping to ball, and couple lines of code to determine actual distance of ball in range of travel. Use value as feedback into your PID algorithm.
FF
good idea, with ping module you mean an ultrasonic sensor, I guess.
I agree in all points.
btw. another nice experiment could be to overlay the set point with a sine function.
Reinhard
That is a very good idea, especially if you record the response of the measured position at the same time. (amplitude of the position sine wave, and relative phase if you can) If you plot this data with various input sine wave frequencies, you can generate a command tracking frequency response plot.
I'm not a fan of using step response for PID tuning. A step command is almost always infeasible, requiring fun things like velocity impulses and infinite accelerations to follow. As such, it mostly tests how well a servo loop recovers from overloads. A step response test will also make any controller with feed forward and or an integrator(s) look bad even if these controllers give better performance when smooth commands are used. (i.e. feasible commands, that the system has the power to physically follow)
The oscillation could be from a bunch of things. Is the oscillation happening at 1/2 the servo loop update frequency? If so, one or more of the loop gains is too high to use at that sampling frequency. If it's slower, I'd next look at the Quantization on your position feedback. I.e. is that 1-2mm jump one count on your ADC?
The oscillation could be from a bunch of things. Is the oscillation happening at 1/2 the servo loop update frequency? If so, one or more of the loop gains is too high to use at that sampling frequency. If it's slower, I'd next look at the Quantization on your position feedback. I.e. is that 1-2mm jump one count on your ADC?
hmm, could it be the oscillation is an effect from the balls own magnetism, which cause a randomized moment of force ?
I am not an expert in system theorie, but in fact a PD controller should be enough.
But I see an integral part is needed. Could it be this avoid an uncontrolled build up of the oscillation ?
However, I get to measure the frequency and follow your tips to determine the reason.
I think many interest findings waiting for me.
I doubt the oscillation is due to the balls magnetism.
The integral component is used to remove steady state error and I don't think that is much of a concern here. It does this because when you get close to the set point the error is small and so the P term is small, the D term is also small or zero. The I builds up over time and corrects the error.
I doubt the oscillation is due to the balls magnetism.
The integral component is used to remove steady state error and I don't think that is much of a concern here. It does this because when you get close to the set point the error is small and so the P term is small, the D term is also small or zero. The I builds up over time and corrects the error.
Thank you for this short and clean summary.
Same I can read in the scripts from my prof, 1000 years ago, but scattered in many pages and hidden behind hundred of formulas.
Since then I have never practice in control loops, but this experiment I have in mind over years.
With the propeller platform, I have seen a chance to realize it and I know, believe, hope I can solve the problem. ( I guess 60% is done )
Maybe in next days I am little quiet, but I continue working on it in my own interesst.
I did control as an undergraduate and did a lot of very complicated things with s planes and laplace transforms that I now forget however my knowledge of what the P, I and D components mean came after implementing them as you are doing. It is a great learning experience.
Hi,
the ball is very stable now, has no oscillation in vertical axis, only over the time it gets a spin.
spin get faster and faster like a globe, but no oscillation.
what's goes one ?
the thing is I have replaced the pwm with the 8bit DAC.
the position signal (from hallsensor) is very smooth, no great dynamic.
only if I go with osci in mV range , I can see spikes.
I make a movie, but there is always the trouble with upload.
to see all, the vid become easy over 200MB.
Its a fun!
Reinhard
edit: have forgot to say it runs in a single cog now. -mcog -Os and used ca. 1200 Bytes.
Hi,
the ball is very stable now, has no oscillation in vertical axis, only over the time it gets a spin.
spin get faster and faster like a globe, but no oscillation.
what's goes on?
That is a very good question and probably not an easy question to answer. Firstly the ball will have very little resistance to rotation so it will not take much to create a rotation.
I recently had some problems with very power full magnets that I glued in to a tubular shaft. I was sure the tube was bent because it would rock back and forth on a flat surface. The first issue was that the magnet was attracted to the granite surface place I was using, then when I tried a wooden surface I discovered it was acting as a compass only it aligned it self flat with the earth because it was laid down. So confusing!
Small oscillations in the magnetic field and a slightly eccentric magnetic field from the ball might create a rotation, perhaps. The earths field might even get involved.
I give the PWM signal with a RC Filter with a timeconstant = 10ms to the power transistor.
even so I see the modulation on the collector from transistor.
I try the DAC, because I tough the signal get smoother and less noisy.
(keep in mind my flying setup)
I can optimize the pwm freq. and the filter, but I want make this comparison.
I like pwm, butI can not fight on all to same time.
I would just drive the transistor to saturation with the PWM signal as long as the frequency is reasonably high (khz) there is no need to filter it smooth as it will be mechanically filtered by the balls inertia anyway.
Well one reason transistors are often driven with the unfiltered PWM is because it means the transistors are either fully on (R is low so I^2R is low) or fully of (I is zero so I^2R is low). So it may be more efficient however it may buzz depending on the frequency.
BTW, here is some really simple code that creates PWM with the counters, supplied by JonnyMac, notice that it has a loop of a fixed period. As very little happens within that loop you have plenty of time to do processing so it is possible to put the PID processing in there as long as you do not try to go to too high a frequency. In fact it might be better to only do the pid processing every n cycles of the PWM, there is little point updating the duty on every cycle.
pri pwmx2(xpin, xpntr, ypin, ypntr) | sync ' launch with cognew()
'' Runs fixed-frequency PWM on xpin and ypin
'' -- pwm frequency set with system constant (PWM_TIX)
'' -- reads duty cycle (in clock ticks) from longs at xpntr and ypntr
'' -- runs in own cog
ctra := (%00100 << 26) | xpin ' PWM / NCO
frqa := 1 ' setup frq for pwm
dira[xpin] := 1 ' make pin an output
ctrb := (%00100 << 26) | ypin
frqb := 1
dira[ypin] := 1
sync := cnt ' sync timing
repeat
phsa := -long[xpntr] ' update x motor speed
phsb := -long[ypntr] ' update y motor speed
' You can insert a lot of code here!!!!!
waitcnt(sync += PWM_TIX) ' let period expire
Thank you for this snippet.
I do the PID algo in the < insert a lot of code section > so the controll output is synchronized with each sample, I see.
Will try that tomorrow.
And even translated the paragraph. I think this paragraph refers to these passive devices: http://www.levitron.com/
They have only PM magnets, no electronics but require the user to spin the floating magnet at the start. I assume this is done to ensure that the pole is always oriented correctly so that the repulsion from the annular lower magnet keeps it centralized and floating. Otherwise the magnet would rotate and crash.
In your case gravity helps to stabilise and the attraction is from a single area not a ring so no need for rotation.
the position signal (from hallsensor) is very smooth, no great dynamic.
only if I go with osci in mV range , I can see spikes.
.
how I wrote in the previous post, the system is very stable now and in fact I could finished the work.
But I am acquire a taste of it and want to go deeper into matter.
I see the spikes are synchronized with the nCS signal of ADC.
The magnitude of the spikes is not dramatic, 50 mV peak to peak.
The spikes appeares short before the ADC is finished.
The attached picture shows the relationship , upper trace is the output from hallsensor, lower is the nCS signal.
Further it is to see the sampling rate is 25kSamples/sec.
-> 35 µs for ADC + 5µs for computing the next controll output.
the ADC time is faster than I posted previous, because it is running in a single cog now, this is faster.
Otherhand if I make an extra delay of few µs, has no negative effect.
Before I try Graham's synchronized pwm solution, I am interesst in another aspect.
I start a second cog, the can observe the control process and send data about states to PC.
Of course so not all samples can detected, but the tendency.
Thats could be a nice demo about propellers ability together with GCC !
( in coherence with an actual flame)
Comments
good idea, with ping module you mean an ultrasonic sensor, I guess.
Reinhard
Yep!
FF
That is a very good idea, especially if you record the response of the measured position at the same time. (amplitude of the position sine wave, and relative phase if you can) If you plot this data with various input sine wave frequencies, you can generate a command tracking frequency response plot.
I'm not a fan of using step response for PID tuning. A step command is almost always infeasible, requiring fun things like velocity impulses and infinite accelerations to follow. As such, it mostly tests how well a servo loop recovers from overloads. A step response test will also make any controller with feed forward and or an integrator(s) look bad even if these controllers give better performance when smooth commands are used. (i.e. feasible commands, that the system has the power to physically follow)
The oscillation could be from a bunch of things. Is the oscillation happening at 1/2 the servo loop update frequency? If so, one or more of the loop gains is too high to use at that sampling frequency. If it's slower, I'd next look at the Quantization on your position feedback. I.e. is that 1-2mm jump one count on your ADC?
Lawson
hmm, could it be the oscillation is an effect from the balls own magnetism, which cause a randomized moment of force ?
I am not an expert in system theorie, but in fact a PD controller should be enough.
But I see an integral part is needed. Could it be this avoid an uncontrolled build up of the oscillation ?
However, I get to measure the frequency and follow your tips to determine the reason.
I think many interest findings waiting for me.
Thanks
Reinhard
The integral component is used to remove steady state error and I don't think that is much of a concern here. It does this because when you get close to the set point the error is small and so the P term is small, the D term is also small or zero. The I builds up over time and corrects the error.
Graham
Thank you for this short and clean summary.
Same I can read in the scripts from my prof, 1000 years ago, but scattered in many pages and hidden behind hundred of formulas.
Since then I have never practice in control loops, but this experiment I have in mind over years.
With the propeller platform, I have seen a chance to realize it and I know, believe, hope I can solve the problem. ( I guess 60% is done )
Maybe in next days I am little quiet, but I continue working on it in my own interesst.
best regards
Reinhard
Graham
the ball is very stable now, has no oscillation in vertical axis, only over the time it gets a spin.
spin get faster and faster like a globe, but no oscillation.
what's goes one ?
the thing is I have replaced the pwm with the 8bit DAC.
the position signal (from hallsensor) is very smooth, no great dynamic.
only if I go with osci in mV range , I can see spikes.
I make a movie, but there is always the trouble with upload.
to see all, the vid become easy over 200MB.
Its a fun!
Reinhard
edit: have forgot to say it runs in a single cog now. -mcog -Os and used ca. 1200 Bytes.
That is a very good question and probably not an easy question to answer. Firstly the ball will have very little resistance to rotation so it will not take much to create a rotation.
I recently had some problems with very power full magnets that I glued in to a tubular shaft. I was sure the tube was bent because it would rock back and forth on a flat surface. The first issue was that the magnet was attracted to the granite surface place I was using, then when I tried a wooden surface I discovered it was acting as a compass only it aligned it self flat with the earth because it was laid down. So confusing!
Small oscillations in the magnetic field and a slightly eccentric magnetic field from the ball might create a rotation, perhaps. The earths field might even get involved.
Why did you decide to ditch the PWM?
Graham
even so I see the modulation on the collector from transistor.
I try the DAC, because I tough the signal get smoother and less noisy.
(keep in mind my flying setup)
I can optimize the pwm freq. and the filter, but I want make this comparison.
I like pwm, butI can not fight on all to same time.
Reinhard
Graham
I try it again without RC to see the effect.
Reinhard
BTW, here is some really simple code that creates PWM with the counters, supplied by JonnyMac, notice that it has a loop of a fixed period. As very little happens within that loop you have plenty of time to do processing so it is possible to put the PID processing in there as long as you do not try to go to too high a frequency. In fact it might be better to only do the pid processing every n cycles of the PWM, there is little point updating the duty on every cycle.
pri pwmx2(xpin, xpntr, ypin, ypntr) | sync ' launch with cognew() '' Runs fixed-frequency PWM on xpin and ypin '' -- pwm frequency set with system constant (PWM_TIX) '' -- reads duty cycle (in clock ticks) from longs at xpntr and ypntr '' -- runs in own cog ctra := (%00100 << 26) | xpin ' PWM / NCO frqa := 1 ' setup frq for pwm dira[xpin] := 1 ' make pin an output ctrb := (%00100 << 26) | ypin frqb := 1 dira[ypin] := 1 sync := cnt ' sync timing repeat phsa := -long[xpntr] ' update x motor speed phsb := -long[ypntr] ' update y motor speed ' You can insert a lot of code here!!!!! waitcnt(sync += PWM_TIX) ' let period expireGraham
I do the PID algo in the < insert a lot of code section > so the controll output is synchronized with each sample, I see.
Will try that tomorrow.
Reinhard
"the system stability is based on rotation of the floating magnet around the axis from his dipol momentum"
Could this be the reasen of the spinning ?
On same paper I found another electronic circuit about this issue.
If you are interesst I can post it.
best regards
Reinhard
And even translated the paragraph. I think this paragraph refers to these passive devices: http://www.levitron.com/
They have only PM magnets, no electronics but require the user to spin the floating magnet at the start. I assume this is done to ensure that the pole is always oriented correctly so that the repulsion from the annular lower magnet keeps it centralized and floating. Otherwise the magnet would rotate and crash.
In your case gravity helps to stabilise and the attraction is from a single area not a ring so no need for rotation.
Graham
how I wrote in the previous post, the system is very stable now and in fact I could finished the work.
But I am acquire a taste of it and want to go deeper into matter.
I see the spikes are synchronized with the nCS signal of ADC.
The magnitude of the spikes is not dramatic, 50 mV peak to peak.
The spikes appeares short before the ADC is finished.
The attached picture shows the relationship , upper trace is the output from hallsensor, lower is the nCS signal.
Further it is to see the sampling rate is 25kSamples/sec.
-> 35 µs for ADC + 5µs for computing the next controll output.
the ADC time is faster than I posted previous, because it is running in a single cog now, this is faster.
Otherhand if I make an extra delay of few µs, has no negative effect.
Before I try Graham's synchronized pwm solution, I am interesst in another aspect.
I start a second cog, the can observe the control process and send data about states to PC.
Of course so not all samples can detected, but the tendency.
Thats could be a nice demo about propellers ability together with GCC !
( in coherence with an actual flame)
best regards
Reinhard
If the pid thread is started, in the main loop I printf out the DAC and ADC values.
become data into PC is easy with
then I process data further with external tool, rather I write own analyse tool.
in steady state the ADC value is setpoint +- 2 digits.