You can probably achieve the same objective without writing an interrupt handler. For example, you could have a task that initiates a conversion and then does a WaitForInterval() with the interval time set to just exceed the calculated conversion time.mikep wrote:If you want to process values while waiting for other conversions to complete, then you should look into writing a native mode ISR for the ADC complete interrupt.
Could be possible to use the ADC in free running mode?
- Don Kinzer
Using this method the smallest wait between successive calls to GetADC is a clock tick (1.95ms). This means to get all 6 readings could take ~ 11.7 ms. For most applications this would work but Ben has said that the current implementation too slow. The WaitForInterval() technique does allow other processing but has a maximum update frequency of ~85 Hz. Ultimately we need a little more information from him about the requirements.dkinzer wrote:You can probably achieve the same objective without writing an interrupt handler. For example, you could have a task that initiates a conversion and then does a WaitForInterval() with the interval time set to just exceed the calculated conversion time.mikep wrote:If you want to process values while waiting for other conversions to complete, then you should look into writing a native mode ISR for the ADC complete interrupt.
Mike Perks
Don / Mike. Thanks for all your thoughts on this.
Basic requirement is to collect 6 adc channels and then perform various filtering and PID feedback loops. I need my overall loop speed to be > 500hz in order to maintain stable operation (flight).
Obviously the sensor fusion and PID functions take up a reasonable amount of time, so Im looking to save time where I can. One area where I thought I might be able to save some time after reading this thread is in the ADC calls.
I have got around the problem initially by just being a bit more froogle on my calls, so now ive got gyro readings (2 adc) coming in every loop (550hz), accelerometers (4adc) data every second loop (275hz) and other sensors (presure, mag) coming in at 30hz. This frees up quite a lot of time.
However as the math code keeps getting added to my main loop, the likelyhood of dropping under 500hz is getting higher. So any time I can save is a bonus!
Ben
Basic requirement is to collect 6 adc channels and then perform various filtering and PID feedback loops. I need my overall loop speed to be > 500hz in order to maintain stable operation (flight).
Obviously the sensor fusion and PID functions take up a reasonable amount of time, so Im looking to save time where I can. One area where I thought I might be able to save some time after reading this thread is in the ADC calls.
I have got around the problem initially by just being a bit more froogle on my calls, so now ive got gyro readings (2 adc) coming in every loop (550hz), accelerometers (4adc) data every second loop (275hz) and other sensors (presure, mag) coming in at 30hz. This frees up quite a lot of time.
However as the math code keeps getting added to my main loop, the likelyhood of dropping under 500hz is getting higher. So any time I can save is a bonus!
Ben
-
liam.zbasic
- Posts: 163
- Joined: 24 March 2008, 23:33 PM
- Location: Southern California (Blue)
You need more than 500Hz to maintain stable flight? For manned aircraft, rigid body dynamics are in the order 1Hz (and less), so we typically do not sample beyond 25Hz (rough order of magnitude). I can see that the rigid body dynamics of an R/C type aircraft will be higher, and this is why you need 500Hz+ sampling. Or maybe you're trying to suppress structural modes, or maybe you're dealing with a wind tunnel model? Interesting subject. Thanks for your original thread.
If the craft really needs that much processing speed, it may be wiser to split the duties between multiple processors. I've found that when I start pushing the limits of the platform right from the beginning, there's usually problems down the road.
In this particular case, you could offload the math to another chip, using the one you have now to just collect the data.
Of course, you may have already pursued this line of logic and found it nor appropriate for the task.
-Don
In this particular case, you could offload the math to another chip, using the one you have now to just collect the data.
Of course, you may have already pursued this line of logic and found it nor appropriate for the task.
-Don
Could be possible to use the ADC in free running mode?
I haven't been following this thread closely, but unless the conversion time of the ADC is the limiting factor, wouldn't a native mode device give him the speed he needs?
Ben, this statement helps but doesn't help if you know what I mean. I guess a quadcopter means 4 motors and 4 PWMs. Quite an advanced project.sturgessb wrote:The platform is quadcopter UAV, hence need for 500hz +.
Why are you sampling at 500 Hz? The refresh frequency for the PWMs cannot be more than 50 or 100 times a second. There is a method to get better ADC accuracy by oversampling as described in this Atmel application note. Is this what you are trying to do?
In general Don's comment about potentially pushing the limits of the platform may or may not be true. I would tend to stick to the single chip until you find a major problem and resolve it. If you have structured your code correctly, moving it to another device and setting up a slave won't be too bad. I assume you are not employing quadrature encoders on the motors and are simply calibrating them and using PID to control them.
Are you looking at or using 16:16 fixed point number to speed calculations?
Mike Perks
To Don:
I have thought about splitting the tasks across two chips, but worry is about speed of communication between the two. How would this be achieved?
To Mike:
Sorry, was just about to rush out the door, hence my haste. Yes quadcopter is 4 brushless motors controlled by 4 PWM escs. Im slightly confused by your comment...
"The refresh frequency for the PWMs cannot be more than 50 or 100 times a second"
Do this, do you mean the standard update rate for motor ESCs is 50-100hz? If so, I've got around this buy using custom controllers capable of update speed of 400hz.
However If you mean the harware PWM outputs on the ZX cannot be updated more than 50-100 times a second, im a bit confused. As I have mine running at 400hz update (i.e a new HPWM command every 1/400sec) and it appears to be working...?!
I have it balancing on the bench really nicely using PID type control. snapping to setpoint position very quickly. Ill post some videos up.
To be honest now, with tweaking my code a bit to only get the samples exactly when i need them, im achieving the speed i need. And as it turns out 350hz update seems more than enough for stability, so I have a bit more headroom now.
Thanks for all the input, ill keep you posted on the project.
I have thought about splitting the tasks across two chips, but worry is about speed of communication between the two. How would this be achieved?
To Mike:
Sorry, was just about to rush out the door, hence my haste. Yes quadcopter is 4 brushless motors controlled by 4 PWM escs. Im slightly confused by your comment...
"The refresh frequency for the PWMs cannot be more than 50 or 100 times a second"
Do this, do you mean the standard update rate for motor ESCs is 50-100hz? If so, I've got around this buy using custom controllers capable of update speed of 400hz.
However If you mean the harware PWM outputs on the ZX cannot be updated more than 50-100 times a second, im a bit confused. As I have mine running at 400hz update (i.e a new HPWM command every 1/400sec) and it appears to be working...?!
I have it balancing on the bench really nicely using PID type control. snapping to setpoint position very quickly. Ill post some videos up.
To be honest now, with tweaking my code a bit to only get the samples exactly when i need them, im achieving the speed i need. And as it turns out 350hz update seems more than enough for stability, so I have a bit more headroom now.
Thanks for all the input, ill keep you posted on the project.
One device is either a SPI or I2C slave. You would need to work out your own application-level protocol.sturgessb wrote:I have thought about splitting the tasks across two chips, but worry is about speed of communication between the two. How would this be achieved?
What I meant was I cannot imagine needing a calculation cycle time of more than 50 or 100 Hz. Is the machine really that unstable that it needs refreshing at 350 Hz? Isn't the whole point of PID to integrate over time and smooth out responses? Perhaps more tuning of the PID constants is needed? I'm sure you have more experience than me in this area and the theory of PID doesn't always match the practice.sturgessb wrote:Im slightly confused by your comment...
"The refresh frequency for the PWMs cannot be more than 50 or 100 times a second"
I would love to see them.sturgessb wrote:I have it balancing on the bench really nicely using PID type control. snapping to setpoint position very quickly. Ill post some videos up.
Mike Perks
I just read up on cascaded control. Is this something you have considered? It may reduce the cycle time at the added expense of extra calculations.sturgessb wrote:I have it balancing on the bench really nicely using PID type control. snapping to setpoint position very quickly.
Mike Perks
Yeah, not too impressed by how they fly, they sure are intelligent units but don't seem to fly that great.
These guys are achieving great results, using 644p
www.mikrokopter.de
Waiting for some new gyros, but i should be in the air soon. ill post up my flight, and inevitable crash!
These guys are achieving great results, using 644p
www.mikrokopter.de
Waiting for some new gyros, but i should be in the air soon. ill post up my flight, and inevitable crash!
This is very interesting. I have always been interested in autonomous navigation, starting back in the days a couple of decades ago when I built a little thing that would approach a light, aim a little rubberband powered lance and fire a pencil at the light. As long as the wattage of the bulb was always the same, it could deduce the range from intensity and come close with the projectile. No binocular "vision".
My question is why you use 4 motors. Why not a standard RC electic helicopter with a couple gyros. The gyros will do their own feedback for stability, then the CPU just feeds control for height, orientation and speed.
It seems as controlling 4 motors would be more complex, and require a lot of custom hardware to do so. Isn't it easier to start with a bunch of commercially available solutions and add to them?
BTW, I have been evolving some ideas for a autonomous GPS/ultrasonic ranger blimp. I think that LiPo batteries may be light enough and have enough power to do a reasonable job of powering the motors and GPS for a reasonable period of time.
-Tony
My question is why you use 4 motors. Why not a standard RC electic helicopter with a couple gyros. The gyros will do their own feedback for stability, then the CPU just feeds control for height, orientation and speed.
It seems as controlling 4 motors would be more complex, and require a lot of custom hardware to do so. Isn't it easier to start with a bunch of commercially available solutions and add to them?
BTW, I have been evolving some ideas for a autonomous GPS/ultrasonic ranger blimp. I think that LiPo batteries may be light enough and have enough power to do a reasonable job of powering the motors and GPS for a reasonable period of time.
-Tony