UAV DevBoard pilots,This is an update on a few UAV DevBoard related activities.There is a new release (1.6) of MatrixNav, that now includes rudder-elevator mixing, and yaw stabilization in both stabilized and and RTL mode. It is available under the UAV DevBoard tab.Ben Levitt just created a couple of groups in the DevBoard code repository. The groups are intended for open source development of firmware for the board. Anyone interested in helping or in monitoring our activities is invited to join the groups. There are several activities on the near horizon, including telemetry, waypoints, helicopter control, and altitude hold, for example.Also, Ben has figured out how to use the spare pins on the board to implement extra interrupt-driven PWM inputs and outputs, bringing the total to 5 PWM inputs and 6 PWM outputs. This considerably opens up the the possible applications of the board. Ben has implemented and tested the firmware for the extra channels, but has not yet released it. It will be available soon. You can see his code here.Best regards,Bill Premerlani
I'd like to help test. Unfortunately, I do not have a quadrotor, or even a UAV dev board at the moment. I also understand that the dev board would have to be modified to access the new PWM output pins, and I'm not equipped at the moment to do this (but perhaps I can get someone to do this for me). Finally, I believe that the gyro on the UAV dev board is not suitable for use in hovering vehicles. If any of this changes, then I will let you know.
I am interested in implementing the algorithms in the original Mahony et al paper, perhaps using quaternions instead of DCM (just to understand quaternions than any other reason). I'd also like to implement my own sensor processing and control schemes. I also think the dsPIC is an interesting chip. However, right now my friend Brij is working on his own custom control & sensor board based on an ATMega 644p.
If I have time, I may check out your code, but I am not able to commit to testing it at this time.
Roy, I agree with Bill that the SW Ins and Outs should run just fine. And in the small amount of testing I've done, they seem to run smoothly. But unfortunately I haven't had time to do very much testing yet.
If you'd like to help test, I can send you setup and usage instructions. :)
I'd like to hold off on making an official release until I can do more testing. But for now, as Bill pointed out, the code is in a public svn repository so anyone who would like to can help me test it out!
Also note that I'm almost done adding the ability to configure the firmware to control different kinds of Airframes, like V-Tails, Delta Wings, and more experimentally, Helicopters. So maybe, with your help, we could fairly easily add Quadcopter as another airframe type.
There should not be any issues at all with the software/interrupt PWM control. I have not tested the extra channels myself yet, I expect Ben will comment on his testing, but Ben is using a technique that I used with the board I was using 5 years ago, and it works just fine.
The question centers on latency variation in processing the spare PWM channels.
First, just to clarify, there are 4 hardware PWM inputs and 3 hardware PWM outputs, 1 software PWM input, and 3 software PWM outputs. In any case, you could use hardware PWM inputs for all 4 motors.
The dsPIC30F4011 has vectored interrupts with programmable priority and a separate interrupt handler for each interrupt source. Ben and I have given the PWM interrupts the highest priority, so no other processing will interfere. The hardware PWM I/O is not affected by latency of processing interrupts, so the only latency to consider is for the processing of the 1 PWM software input, and 3 PWM software outputs.
The Rx sends pulses sequentially, so the PWM inputs will not interfere with each other's latency.
The firmware that Ben has written sends the PWM output pulses sequentially, so they will not interfere with each other's latency.
The only other case to consider is when the processing of a PWM input interrupt and a PWM output interrupt overlap. The probability of that happening is not zero, but it is very low, on the order of 1 out of 10,000, because the PWM interrupt processing is very short, its only a few instructions, taking about 1 microsecond.
If you work the numbers out, about once an hour, a software PWM output pulse will be lengthened by 1 microsecond.
For all practical purposes, the software PWM channels that Ben has implemented for the UAV DevBoard should be every bit as good as the hardware PWM channels.
The extra PWM I/O sounds promising for my quadrotor project. Do you think there would be any issues with having 3 motors controlled via hardware PWM and one via software/interrupt? Is there any risk of an asymmetric response?
Comments
I'd like to help test. Unfortunately, I do not have a quadrotor, or even a UAV dev board at the moment. I also understand that the dev board would have to be modified to access the new PWM output pins, and I'm not equipped at the moment to do this (but perhaps I can get someone to do this for me). Finally, I believe that the gyro on the UAV dev board is not suitable for use in hovering vehicles. If any of this changes, then I will let you know.
I am interested in implementing the algorithms in the original Mahony et al paper, perhaps using quaternions instead of DCM (just to understand quaternions than any other reason). I'd also like to implement my own sensor processing and control schemes. I also think the dsPIC is an interesting chip. However, right now my friend Brij is working on his own custom control & sensor board based on an ATMega 644p.
If I have time, I may check out your code, but I am not able to commit to testing it at this time.
Thanks
Roy
Roy, I agree with Bill that the SW Ins and Outs should run just fine. And in the small amount of testing I've done, they seem to run smoothly. But unfortunately I haven't had time to do very much testing yet.
If you'd like to help test, I can send you setup and usage instructions. :)
I'd like to hold off on making an official release until I can do more testing. But for now, as Bill pointed out, the code is in a public svn repository so anyone who would like to can help me test it out!
Also note that I'm almost done adding the ability to configure the firmware to control different kinds of Airframes, like V-Tails, Delta Wings, and more experimentally, Helicopters. So maybe, with your help, we could fairly easily add Quadcopter as another airframe type.
Ben
There should not be any issues at all with the software/interrupt PWM control. I have not tested the extra channels myself yet, I expect Ben will comment on his testing, but Ben is using a technique that I used with the board I was using 5 years ago, and it works just fine.
The question centers on latency variation in processing the spare PWM channels.
First, just to clarify, there are 4 hardware PWM inputs and 3 hardware PWM outputs, 1 software PWM input, and 3 software PWM outputs. In any case, you could use hardware PWM inputs for all 4 motors.
The dsPIC30F4011 has vectored interrupts with programmable priority and a separate interrupt handler for each interrupt source. Ben and I have given the PWM interrupts the highest priority, so no other processing will interfere. The hardware PWM I/O is not affected by latency of processing interrupts, so the only latency to consider is for the processing of the 1 PWM software input, and 3 PWM software outputs.
The Rx sends pulses sequentially, so the PWM inputs will not interfere with each other's latency.
The firmware that Ben has written sends the PWM output pulses sequentially, so they will not interfere with each other's latency.
The only other case to consider is when the processing of a PWM input interrupt and a PWM output interrupt overlap. The probability of that happening is not zero, but it is very low, on the order of 1 out of 10,000, because the PWM interrupt processing is very short, its only a few instructions, taking about 1 microsecond.
If you work the numbers out, about once an hour, a software PWM output pulse will be lengthened by 1 microsecond.
For all practical purposes, the software PWM channels that Ben has implemented for the UAV DevBoard should be every bit as good as the hardware PWM channels.
Best regards,
Bill
- Roy