CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Float variable for pwm duty

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Rodders



Joined: 04 Mar 2010
Posts: 12
Location: Birmingham

View user's profile Send private message

Float variable for pwm duty
PostPosted: Mon Mar 22, 2010 7:01 pm     Reply with quote

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



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Mar 22, 2010 8:42 pm     Reply with quote

Quote:

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.

See this recent thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=42010
Rodders



Joined: 04 Mar 2010
Posts: 12
Location: Birmingham

View user's profile Send private message

PostPosted: Mon Mar 22, 2010 9:03 pm     Reply with quote

PCM programmer wrote:
Quote:

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.

See this recent thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=42010

Thank you.
Rodders



Joined: 04 Mar 2010
Posts: 12
Location: Birmingham

View user's profile Send private message

PostPosted: Tue Mar 23, 2010 6:15 pm     Reply with quote

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



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Wed Mar 24, 2010 5:51 am     Reply with quote

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



Joined: 17 Sep 2003
Posts: 331

View user's profile Send private message

PostPosted: Wed Mar 24, 2010 6:20 am     Reply with quote

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



Joined: 04 Mar 2010
Posts: 12
Location: Birmingham

View user's profile Send private message

Oscillation Problem
PostPosted: Wed Mar 24, 2010 8:06 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19477

View user's profile Send private message

PostPosted: Wed Mar 24, 2010 10:23 am     Reply with quote

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



Joined: 04 Mar 2010
Posts: 12
Location: Birmingham

View user's profile Send private message

PostPosted: Mon Mar 29, 2010 10:41 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19477

View user's profile Send private message

PostPosted: Mon Mar 29, 2010 3:08 pm     Reply with quote

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



Joined: 09 Aug 2007
Posts: 82
Location: TN, India

View user's profile Send private message Send e-mail

use type conversion method
PostPosted: Tue Mar 30, 2010 9:52 am     Reply with quote

use type conversion method ..

try below code,

Code:
set_pwm1_duty((int)kp);


Cool Karthic Eswaran
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group