Float variable for pwm duty

[Rodders]

HI guys,

I have been implementing PID on my line following robot and I've run into the roadblock because the CCS Manual says that the pwm duty cycle value can not be a float and that only 8 bit or 16 bit integers can be used.

I have even tried using my kp values as float kp=0.0 and the robot just goes haywire. The same code using int kp=0 works just fine. Do you know of any methods I could use to go around this problem.

Kind Regards,

R

[PCM programmer]

[Rodders]

[Rodders]

For our PID control of the robot, sometimes the Robot overshoots when the average speed is set higher. We are currently using kp and kd without ki because whenever we insert ki, the robot is going haywire and we're still trying to work out the correct ki value.

Is it because DC motors can't respond to very quick changes in duty cycle? Would a look ahead sensor improve the turning, by slowing down the moment the lookahead no longer reads the black line? Are 6 sensors a good number for excellent PID control? would you suggest that 7th sensor, the lookahead, be included in the in error calculation?

P.S All the sensors are in line whilst the look ahead gives the sensor array an upside down V shape.

[SherpaDoug]

kd is the constant that deals with quick input changes. For line following I would not expect you need ki at all.

Can you "de-focus" your sensors so you get a more gradual input change as you approach the line?

DC motors respond to PWM changes about as fast as any other type of motor with equal power vs. rotor mass.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[John P]

Could the problem simply be that floating point calculations on a PIC are slow, and the PWM is being set using incomplete results, or the response to conditions is just lagging too much?

So far I've always managed to avoid using floating point, so maybe I've got an exaggerated idea of how long it takes, but if I were doing this I'd want to be sure that everything had enough time to operate.

[Rodders]

Thanks, I was worried much by the prospect that DC motors can't respond to quick PWM changes.

The robot follows the line perfectly fine using just kp, but oscillation becomes a major problem when we increase tp.

http://www.youtube.com/watch?v=-qqBPEvEDoA&feature=channel
The aim is to have a robot that litterally hugs the line at fast speeds as the ones in these competitions.

I initially thought that the response to readings wasn't fast enough at faster speeds but I found out that our sensors have a response time of 8us. I am not sure I understand what's meant by de-focussing the sensors.

[Ttelmah]

The response time of the sensors, is not a problem, but the time needed for FP maths most definitely is.

Now, you have a signal delay introduced by the sensor (small), a response delay from the PWM (it only changes speed, on the _next_ cycle of the PWM), a mechanical inertia in the motor, plus it's drive components, and the time taken to perform the maths. The initial response time, is determined by everything except the inertia (this then affects how quickly the response is applied). The largest of these delays for you, _will_ be the maths. Typically a PID algorithm, will have three products, two additions, and a subtraction. Performing these in FP, even if your chip is running at 40MHz, will take something over 250uSec. Using instead _scaled integer_ maths, with a scale like 256*, allows you to take just the high bytes, and feed these directly to the PWM, without the extra time involved in the conversion. Using a 16MHz chip, and arithmetic done like this, I managed to get the response below 45uSec, massively reducing the lag, and the resulting overshoot...

Defocussing the sensor, is a very good idea. Ideally, you want a 'soft' data response, along the lines of 'you are slightly right', 'you are a lot right', rather than simple switch 'you are right', 'you are left' type inputs.
Imagine you are following a line yourself, and your only light source, is two laser pointers, one pointing just right of the line, and the other just left. You get no position information at all, till you are off the line, and when you are, you get no 'how far' type information. Now instead imagine following the line, with two diffused torches of different colours, both aimed so they actually _touch_ the line slightly. When you are on the line, there is a small amount of light from both. Turn even a tiny fraction one way, and the light from this torch increases. The further you turn, the greater the increase. You receive not only 'off line' information, but a measure of how _far_ off the line you are, allowing much more accurate control.

Best Wishes

[Rodders]

I am now using scaled integers for my PD settings and the oscillation is almost gone.

For further improvement in the efficiency of my comparator circuit, do you guys recon I should use a more modern op-amp like the LM6134 because I have read reviews that the current LM324 isn't the best in terms of sampling rate and linear? Or do most of the adjustments just need to be done in the software for a fast as possible excecution?

By the way, in terms of execution times, which will execute faster a Switch Case statement or a bunch of IF-ELSE IF-ELSE statements?

Regarding defocussing the sensors, will that affect the predifined conditions i have in my code for certain line readings? For instance, during execution, will my code be even entering these predefined conditions?

Thanks again for the help guys.

[Ttelmah]

Lost of different answers to the if-else, versus switch.
A small number of cases (typically about 4 to 5), takes the same amount of time for both. The compiler actually automatically generates the same code.
The switch will be faster for a large number of cases, _provided you don't have a 'default' case_. It is faster to test for the 'out of test range' conditions, with an if, then code the switch to deal _just_ with a known range of numbers. This then codes as a jump table, and is then slower than a 'if' for only the first couple of cases, but faster for all others, and has the big advantage that the response time is constant for all the table entries.

Do you have anything to prevent integrator wind-up, in the PID?. If not, then this is probably your largest remaining problem.

On the op-amp side, it is difficult to answer without knowing a lot more about your circuit. The 324, is entirely 'adequate' for a lot of applications.

Best Wishes

[karthickiw]

use type conversion method ..

try below code,