PID using PICAXE

[c6jones720]

Im using picaxe 18s for use in simple remote positioning servomotors. The picaxe accepts a pwm demand signal (standard radio control signal or servo command) and reads back an error signal from a pot. Now the system Ive got seems to work reasonably well for low precision tracking, but I was thinking about improving the precision by using a PID control algorithm. I wondering if anybody out there had ever used a PID control algorithm with a PICAXE before? Can these chips use floating point arithmetic for the maths or will I have to do it another way?

 

[BeanieBots]

I've done quite a few PID algorithms for PICAXE but the best bandwidth I've ever achieved is a few Hertz. This is fine for applications such as temperature control but would be of little use for motor control. By careful use of integer maths it can be done without the need for floating point arithmatic, especially if you limit the range. I did some investigation into using the floating point co-processor and concluded that the bit-banging interface would make things even slower so never tried the actual device itself.
My advice would be to do the real-time PID loop around op-amps and use the PICAXE to provide the demand ramps etc.

For an example of a PID loop see this thread.
http://www.rev-ed.co.uk/picaxe/forum/Topic.asp?topic_id=2455

Edited by - beaniebots on 7/6/2005 12:42:41 PM

 

[Technical]

The uM_FPU coprocessor can work quite fast via i2c connection to X parts.

 

[BeanieBots]

Good point Technical. When I did the investigation it was with the older uM_FPU which did not support I2C. Maybe it's time to re-evaluate.

 

[ylp88]

Since the term was mentioned, what exactly is "floating point arithmetic"?

As far as I know, I think it is to do with the imprecision of numbers due to infinitely long numbers having to fit in finitely long spaces; and this results in rouding erros when the number is "truncated" or rounded.

Am I right? Is there more to it? I couldn't find much on the nternet without them getting into long winding "essays" aimed for people with a PhD in maths and computer science!

Thanks for your help anyone...

ylp88

 

[hippy]

A simple(ish) explanation of Floating point which isn't necessaily perfect and complete but is probably good enough to start with.

Fixed point first: "AB.CDE" is a fixed point, five digit number ranging from 00.000 to 99.999 in decimal. Because the decimal point is always after the second digit the number can be stored in memory as "ABCDE"; we always know where the decimal point is, so we know what that represents.

Floating Point allows the decimal point to be moved ( "to float about&quot ; "A.BCDE", "AB.CDE", "ABC.DE" etc. We can still store the number as "ABCDE", but to know where the decimal point is, another number/digit has to be stored to indicate its position; "ABCDEP".

In this case P can range from zero ( ".ABCDE" ) to 5 ("ABCDE.&quot, but why not allow P a wider range ? With P being -1, we can represent "0.0ABCDE", with P being 6 we can represent "ABCDE0."

If P is allowed a wide range, you can see that we can represent some quite big and some quite small numbers, but note that with only a limited number of digits ( five in this example ), the actual numbers we can represent exactly is very much finite.

Hopefully that makes sense, but do say if it doesn't.

 

[hippy]

Building on that; precision, truncating and rounding ...

Say we wish to multiple two five digit numbers 1.2345 and 1234.5, the correct, accurate answer is 1523.99025 ( according to Windows Calculator ).

Because we can only store five digits, that can only be stored as "15239" with the decimal point after the 3, so we've lost some accuracy and some precision.

Likewise, 12345 times 12345 is a big number, but we can only keep the first five digits and indicate that the decimal point is way off to the right. What should be 152399025, we can only store as a number which represents 152390000.

Some Floating Point Units may do some rounding which adjusts the last digit up or down.

Another issue arises when dealing with decimal fractions in binary. Each bit after the decimal point represents 1/2, 1/4, 1/8 etc; with three bits after a decimal place, 0.5 = 0.100 in binary, 0.25 = 0.010, 0.125 = 0.001.

But how do we represent 0.6 ?

0.100 = 0.5
0.101 = 0.625 ( 0.5 + 0.125 )

The answer is we can't, not accurately, so this is another area of inaccuracy in Floating Point.

If we just had 0.6 we could have used 6 and indicated the decimal place was before the 6, but in other cases we run back into the problem of having only a limited number of digits we can use.

 

[ylp88]

Thank you very much for your time... Aplogies to c6jones720.

ylp88

 

[c6jones720]

thats alright. Thanks for all the help and advice.
I was actually using op amps and other analogue stuff for my servo control until somebody told me how easy picaxes were to use!
I think I'll probably end up leaving the servo circuit as is and using a computer to monitor the demand and feedback. The PC will work out the PID in a higher level language like C. Ill send the result back to the servo as a new demand signal.

 

[BeanieBots]

You have me a bit confused. The 'servo' is normally the bit that has the PID loop built into it. The 'demand' is fed into the 'servo'. Hence, if your PC is doing the PID loop, then its output will be a signal to something along the lines of power amp to drive the motor. The PC then becomes part of the 'servo'. Unless your PC has the required interface cards to read in the error signal and output a demand signal it will probably be no better than using a PICAXE. This will be especially true if you are using a high level language and not 'talking' directly to the hardware in assembler. High level languages usually use ports to access plugin cards and the associated overhead will kill the PID bandwidth.
Maybe if you could explain exactly what type of loop you are controlling and exactly what your 'servo' does, then there might yet be scope for a PICAXE solution.

 

[BeanieBots]

Thinking more about this, if you already have a solution that is only suffering from being a bit sloppy, have you considered giving the PICAXE the error signal rather than the position feedback? For the sake of a cheap op-amp and a few discretes it would out perform anything a PC could ever do and would negate the need for expensive I/O cards (as well as the PC).
I may yet have completely miss-understood exactly what you are trying to do but my assumption is that you have a position demand signal in the form of an RC type 'servo control' pulse. If this is the case, then continue to use the PICAXE but use it to convert the demand pulse into an analog position demand. Feed the demand voltage into a PID loop built around an op-amp (only a very expensive DSP device will out perform it). The PICAXE can now be used to monitor/track/control the slower elements such as compensating position demand for gearbox backlash, velocity profiling, etc. etc.