High speed motor control (propellers)

[vinniewryan]

I recently built a flying unit that has 4 motors with propellers, an accelerometer, and is controlled by a 16f684 mcu. The function of this unit is to simply keep the unit in the air, and using the accelerometer, balance out so it's always flying level. The problem I've come across is that I don't think the MCU is fast enough (4Mhz) to do this kind of control.

My program is simple. When I turn the unit on, I hold it level and press a button, and the MCU reads the X and Y axes of the accelerometer and saves them as reference variables XC and YC. The C is for 'Center' because this is the value that the ADC reads when the unit is level. Then it enters normal operation mode, turns on all 4 motors, reads X and Y values of accelerometer and compares them to the reference values XC and YC. If X > or < XC, the program tells the appropriate motors to slow down or speed up so the unit can correct its tilt. So in a nutshell, all the program is doing is keeping the flyer aloft and level so it can stay in one place in the air.

In reality, when I turn the flyer on, it tries to correct its tilt but it's impossible to get it to correct accurately enough for it to stay level. I've spent hours, day, weeks adding thresholds, offsets, sensitivities in every possible way to get it to not over or under correct, but no matter how much I improve its performence, I can't get it to work well enough.

My current program is constantly pulsing output_high to each motor, and if that motor needs to decrease speed, I'll output_low for a calculated time(in us) then output_high again. This is obviously not the right way to control motor speed, so I'm wondering what a better, proven method would be.

Would it be wise to use a PWM to control motor speed for 4 separate motors, and if so, is it possible to change the pwm speed fast enough to control all 4 motors simultaneously? Is there a better approach for controlling 4 propellors? Is a 40MHZ oscillator speed fast enough to perform such precise algorithms ? Any suggestions or ideas are appreciated.

Thoughts?
_________________
Vinnie Ryan

[Mike Walne]

Sounds like you've got a classic PID loop control problem.

If you disable one axis, and use only two motors, can you achieve control by hand using a potentiometer (or something similar)?

(i.e. use clockwise rotation of the pot to increase the speed of one motor and decrease the speed of the other & vice-versa)

Mike Walne

[SherpaDoug]

What makes you think processor speed is a problem? Are you using a paced loop to regulate the control loop speed? If so you should be able to tell if there is extra time left at the end of the old cycle before the next cycle is scheduled to begin.

If your code is at all efficient I don't expect processing speed should be a problem. I hope you are not using floating point math!
_________________
The search for better is endless. Instead simply find very good and get the job done.

[vinniewryan]

Now that I think about it from another perspective, I'm certain it's not processing speed, I'm just stuck and don't know what to try next, it feels like I've tried every method.

I would post the code but it's pretty long, has a lot of variables, and would be a headache for anyone to try and examine.

In basic form, there are 2 variables for each motor. We'll call them LMONT and LMOFFT, these stand for 'Left Motor On time' and 'Left Motor Off time', and they represent the amount of time the motor is pulsed on and off respectively. Also, there are two more variables, 'LeftMotorOnCounter' and LeftMotorOffCounter', and these are used to keep track of how long the motor has been on and off for.

When I turn the unit on, the first thing it does is wait for me to hold it level and press the button to calibrate it. When I press the button, it saves the ADC value from the X axis as XC, and the value from the Y axis as YC, as I explained before. At this point, it knows what value each axis should be reading for it to be level and has saved them as XC and YC.

Next, the code enters normal operation. It detects whether it's level or not, and if not, it calculates a new value for LMOFFT and LMONT.

[Wayne_]

My firstthoughts are with this:-

[Ttelmah]

As Mike says, fairly classic.
Problem is the lags involved.
Imagine for a second, that the motor responded 'instantly' to a change in power. Even then, it'd take time for the increase/decrease in thrust to actually correct the platform. Worse, the motors take time to respond, and it takes time for a change to even affect the motor control.
So, the platform tilts right. Control system says 'tilting right', and increases the power to the right motor. Next time round, it still has not responded, so it increases it further. This perhaps happens for several cycles. The platform then starts to respond, beginning to level, but is still tilting right, so another couple of cycles occur before finally the system sees the platform at 'level', but by then, perhaps 20% more power has been applied to the right motor than was actually needed to level it, so it now overshoots...
The classic solution, is an algorithm called 'PID'. What you do, is start with a 'mid range' motor power value. Effectively the average of the power that has been applied long term to the motor. If the platform tends to spend more time tilting right than left, you fractionally increase the power to the right motor. This is the 'long term' tweak value, the 'I' term (integral of past responses). You then look at the immediate error. Tilting right, so you increase the right motor power (the 'P' term), giving a response 'proportional' to the error. You then though look at the current change. Is the platform's angle getting worse, or has it started to slow, or is it beginning to tilt back. If the last two, you _reduce_ the correction applied, or in the last case, actually start to reverse it. Effectively you respond to the 'rate of change' of the position (the 'differential' term - D - how much the position has changed since 'last time').
What you have at the moment, is a rather simple pure 'P' term response, so with the lags both in motor responses, inertia, and even the sensor - the value you read always lags the real position, you end up perpetually overshooting. A 'genuine' P term, would make the adjustment applied actually reflect how far off level the system is, reducing the tweaks at small angles, which would help straight away...
Unfortunately, a full PID algorithm, will use a lot more processing power, so the processor speed will probably begin to be an issue. However the internal oscillator on the PIC you have supports operation at 8MHz, so you can increase the speed by a simple program change, which will help. You might want to try something a little simpler, but based upon this approach. Imaging that you store the required power in a two byte value, with the MSB, being the 'power to apply'. Then in your loop, look at how far off angle the system is, with just a series of step tests. If the unit is badly tilted, add/subtract 256 to the 16bit value, but if it is titled just a few degrees, 128, while if it is tilted, but hardly at all, just 1. Then use the MSB as the power to the motor. This way the adjustment will be very small and slow, if the platform is only tilted a little. Then also look at the change from last time. If the tilt is _less_ than last time, just decrease the adjustment by a single unit.
This gives a very crude PD correction. You can tune the 'factors', by adjusting the size of the numbers added.

Best Wishes

[vinniewryan]

Before I reply to the rest of your comments, let me address a mistake that you both brought up.

This is what I originally posted:

[vinniewryan]

Now that that's out of the way,

Thanks for the responses and suggestions. You suggested setting lmofft to a fixed value as it's my pulse width, I'll try that first. It should help smoothen out the output to the motor. Also, thanks for the syntax pointer, I didn't realize there was actually a reason I never see all CAPS in variable declarations.

Ttelmah,

Thank you for the indepth description, you certainly gave me some ideas and things to try. One idea is, instead of the power of the left motor mirroring the amount of tilt present, to have a new variable that allows me to increment the pulse time to the left motor, kind of like a buffer.

Another thing I have in the actual program that's not here, is a threshold (th) for each axis, which I'll add in just so you have an idea of how I'm preventing constant correction.

[temtronic]

I used to build university level helis like this years ago and know that simple PID will control them(16F877,20MHz) so it is doable!

Don't know if you thought or do this but ...

Please consider that if it's tilting down left to not only incerase the Left motor but ALSO decrease the RIGHT motor at the same time. This will increase the response time.

Also be sure to add some filter caps to the motors.Thay generate noise that your system might pickup ,giving false readings..

Also if you use 8bit math it's faster and easier on the PIC , that's all I used.

Also prop pitch and diameter are critical. Changing to the next size up or down will definitly alter response/performance. And there will be the 'right' one for your heli.

Good luck

Jay

[SherpaDoug]

I think you are still missing an important piece of your control loop. You need to regulate the speed the whole loop operates at. Usually this is done with a "paced loop". The control loop is started by a timer, usually a flag set by a timer interrupt. Once the loop runs and all the measurements are done and motors adjusted, the loop waits for the timer before it starts over again.

This is crucial for a PID algorithm as the I and D terms are time dependent. If the loop speed changes due to the math execution time or the motor duty cycles you will never get things stable.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[newguy]

Google "PID Without a PhD" by Tim Wescott. It's filled with invaluable background information.

[vinniewryan]

temtronic, I'm glad you have experience with this type of project, and you've already made many valuable suggestions. I'll certainly make the opposing motor decrease as the other increases. I do have filter caps on the motors, along with diodes on the power lines to decrease system noise, and doing so made a huge improvement. Also I'll change my variables to 8 bit, I was under the impression that using 16 bit would give me a wider range of values off the ADC axes. The propellors have been specially designed specifically for this project's size/body by an experienced engineer, so now it's up to my programming to make things work out. Thanks for the info, I'll let you know how it works out!

SherpaDoug, I understand how a paced loop would help normalize the timing structure, but it brings up one big question; When "The control loop is started by a timer, usually a flag set by a timer interrupt. Once the loop runs and all the measurements are done and motors adjusted, the loop waits for the timer before it starts over again.", what state should I leave the motors in while they're 'waiting' for the timer before the loop starts over? Should they be on or off? Also, are you suggesting I create a simple timer, or use the built in hardware timer to keep track of the loop timing?

newguy, wow I just looked up the PDF of "PID Without a PhD", read through a few sections and it looks like it will be very helpful, I'll read it tonight, it seems I can learn a lot about what SherpaDoug is suggesting in that document.

Thanks everyone, I have a LOT of things to change and try, and every suggestion brings me closer to succeeding in getting this thing to fly level!
_________________
Vinnie Ryan

[newguy]

Regarding the paced loop, you'll definitely want to do that with a hardware timer and its associated interrupt. The general idea is to run the loop at least 10x faster than any physical 'catastrophic' change will take to occur.

With what you're building, I'd try to measure the time it takes for the thing to tilt some critical amount - 45 degrees? 30 degrees? 5 degrees? (whatever you deem to be critical) - if one motor is running full out while the others are idling/mid-range/whatever. If that takes 500ms, then your control loop needs to run every 50ms, if not faster.

Your timer ISR, once it fires, should measure the x-y-z tilt, then set a flag for your main loop that alerts it that a new tilt is available, and exit. The main loop is where all your processing occurs (motor drive levels), and is triggered by the flag that new data is available. Once the motor drive levels are set by this routine, they stay there until the next time that new data is available. In this manner, your program spends most of its time 'twiddling its thumbs.' ....And that is honestly the best way to lay out a program - do nothing until you're prompted to react to some outside event. Plus you're guaranteed to have rock solid timing for your PID algorithm(s).

The only hard part will be to tune the PID algorithms, but even that shouldn't be that hard. I'd try to isolate the front/back and left/right tuning by disabling a pair of motors and mounting the thing on a knife's edge so that it can only tilt L/R when tuning the L/R algorithm and F/B when tuning the F/B algorithm. Once you get each pair optimized (and depending on the balance/geometry they may end up being identical), you're pretty much guaranteed that they'll work together to get the thing to hover perfectly right off the bat.

[SherpaDoug]

I think Newguy answered your questions pretty well. Keep an eye on the "thumb twiddling" time. When that time gets close to zero you may need to go to a faster CPU speed. You probably don't need a whole lot of resolution so 8 bit ints should do.

You might have a fast timer interrupt to throttle your motors. Each motor has a thrust setting number. The fast interrupt counts down a time number which rolls over at 4 or 8 bits, and compares to each motor's thrust number. If the thrust number is bigger the motor is switched ON, else the motor is switched OFF. Your main program updates the thrust numbers and lets the fast interrupt apply the numbers to the motors on its own.

If you mount the craft to tilt on a horizontal string or wire you should be able to work on one axis at a time.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[vinniewryan]

Thanks for the advice, I took your suggestion SherpaDoug, mounted the flyer on a tensioned fishing line and tested each axis. The first problem I found was that the weight was too high (top heavy), so the downward acceleration was much more powerful than the correcting upward-thrust acceleration. After mounting the weight on the underside of the unit, I immediately saw a major improvement. I was able to make it balance flawlessly on each axis.

Next, I detached the unit from the string so it could free-fly. The first problem that came up was rotation. There is no onboard gyro so I have no way of detecting rotation, so I made a few programming changes, and with the help of all of your advice I was able to create a PID algorithm that pulses the motors at 100hz and it worked like a charm. Now the thing flies level, and no rotation. The next step is to mount my custom $0.30 cent gyro for yaw detection.

Thanks for all the help! I couldn't have done it without your suggestions!
_________________
Vinnie Ryan