Posted by Belli Button on August 22, 2009 at 9:08am
I've been pondering the problem of expanding the number of channels for the UAVDev Board. I think it is possible to have eight input (radio) channels, four output (servo) channels, an altitude (pressure) sensor and an airspeed (pressure) sensor without any modifications to the board. It would require some code changes but I don't think they are difficult.Would it be necessary to add these items? The board would plug on top of the existing headers and would be about half as big as the existing UAVDev board. Is there any interest?
Sorry that I did not respond sooner, today was a good day for flying, and I have been busy polishing up the firmware for the UAV DevBoard.
Regarding the number of PWM input/output channels available on the UAV DevBoard, Ben Levitt has figured out a clever way to use the spare I/O pins on the board to achieve a total of 5 PWM input channels, and 6 PWM output channels. All you would need would be some firmware and a special cable. You would not need any other hardware. As soon as we test his implementation, he plans to post a discussion.
Regarding what I think is needed to get great performance out of a fixed wing aircraft with the UAV DevBoard, all you really need is an EM406 GPS, and the accelerometers and gyros that are already on the board. Magnetometer, altimeter, airspeed measurement, or a better/faster GPS are really not needed with the firmware that I am developing. For a helicopter you might want to have a magnetometer, but for an airplane, I think an "off-the-shelf" DevBoard is more than adequate.
The past few days I have been improving pitch stability and implementing altitude hold for MatrixNav. (I will release it as soon as I write the documentation to go with it.) Along the way, I discovered that the main thing in getting top performance out of the board is taking some simple steps to isolate the board from vibration. I am planning on posting a discussion on the subject as soon as I have some time.
Now that I have dealt with vibration issues, I have been able to achieve very precise, stable pitch control as well as altitude hold, using only an EM406 GPS and the hardware on the board.
Certainly I am not against the use of a magnetometer, altimeter, airspeed sensor, or uBlox GPS, there are some situations where they would further improve performance. But I think there is a lot that you can do with just firmware to improve performance of the EM406 and the gyros and accelerometers that are on the board, if you take some basic steps to prevent vibration from interfering with the inherent accuracy of the DCM algorithm. My plan is to continue to improve the performance of the firmware for the UAV DevBoard, using only the hardware that is already there.
Finally, regarding the I2C interface to the dsPIC, it would be possible to provide an I2C interface to the board. I actually did something similar for a friend of mine who wanted a control board for his 21 foot sailboat. I built a custom board for him, very similar to the DevBoard, in which two pins were shared by both the ICD2 connection, and an I2C interface.
You could do something similar with the UAV DevBoard. It would be messy, but it could be done. Here is what you would have to do:
1. If you wanted to be able to run the ICD2 as a debugger for the dsPIC, you would have to give up the spare serial port.
2. You would need to run the 6 wire ICD2 connection through the shield. The main reason is that you would have to be able to switch the PGC and PGD lines on the dsPIC between the ICD2 and the I2C interface.
3. In the firmware configuration, you would need to specify EMUC2 and EMUD2 as the debugging port. You would use the shield to connect PGC line from the ICD2 to EMUC2, and the PGD line to EMUD2.
What happens is that you would program the dsPIC via the PGD and PGC pins, but you would debug it via EMUD2 and EMUC2. While you were programming, you would set the switches on the shield to connect the ICD2 to the dsPIC. When you were ready to either debug or run the firmware, you would set the switches on the shield to connect the I2C interface to the board.
I would certainley be interested, would pair nicley with the ublox gps breakout board of Jordi's which I beleive will allow the UAVDev board to be used with the ublox gps.
Also having looked at the data sheet of the dsPIC fitted to the UAVDevboard I believe the pins for the hardware I2C unit could be used via the ICD2 header, however this would remove the ability to use the ICD2 as a debugger and I havn't looked into it in great detail.
This would allow an magnetometer / compass module to be attached to the board along with other I2C elements such as the open servo.
Replies
Cheers
Sorry that I did not respond sooner, today was a good day for flying, and I have been busy polishing up the firmware for the UAV DevBoard.
Regarding the number of PWM input/output channels available on the UAV DevBoard, Ben Levitt has figured out a clever way to use the spare I/O pins on the board to achieve a total of 5 PWM input channels, and 6 PWM output channels. All you would need would be some firmware and a special cable. You would not need any other hardware. As soon as we test his implementation, he plans to post a discussion.
Regarding what I think is needed to get great performance out of a fixed wing aircraft with the UAV DevBoard, all you really need is an EM406 GPS, and the accelerometers and gyros that are already on the board. Magnetometer, altimeter, airspeed measurement, or a better/faster GPS are really not needed with the firmware that I am developing. For a helicopter you might want to have a magnetometer, but for an airplane, I think an "off-the-shelf" DevBoard is more than adequate.
The past few days I have been improving pitch stability and implementing altitude hold for MatrixNav. (I will release it as soon as I write the documentation to go with it.) Along the way, I discovered that the main thing in getting top performance out of the board is taking some simple steps to isolate the board from vibration. I am planning on posting a discussion on the subject as soon as I have some time.
Now that I have dealt with vibration issues, I have been able to achieve very precise, stable pitch control as well as altitude hold, using only an EM406 GPS and the hardware on the board.
Certainly I am not against the use of a magnetometer, altimeter, airspeed sensor, or uBlox GPS, there are some situations where they would further improve performance. But I think there is a lot that you can do with just firmware to improve performance of the EM406 and the gyros and accelerometers that are on the board, if you take some basic steps to prevent vibration from interfering with the inherent accuracy of the DCM algorithm. My plan is to continue to improve the performance of the firmware for the UAV DevBoard, using only the hardware that is already there.
Finally, regarding the I2C interface to the dsPIC, it would be possible to provide an I2C interface to the board. I actually did something similar for a friend of mine who wanted a control board for his 21 foot sailboat. I built a custom board for him, very similar to the DevBoard, in which two pins were shared by both the ICD2 connection, and an I2C interface.
You could do something similar with the UAV DevBoard. It would be messy, but it could be done. Here is what you would have to do:
1. If you wanted to be able to run the ICD2 as a debugger for the dsPIC, you would have to give up the spare serial port.
2. You would need to run the 6 wire ICD2 connection through the shield. The main reason is that you would have to be able to switch the PGC and PGD lines on the dsPIC between the ICD2 and the I2C interface.
3. In the firmware configuration, you would need to specify EMUC2 and EMUD2 as the debugging port. You would use the shield to connect PGC line from the ICD2 to EMUC2, and the PGD line to EMUD2.
What happens is that you would program the dsPIC via the PGD and PGC pins, but you would debug it via EMUD2 and EMUC2. While you were programming, you would set the switches on the shield to connect the ICD2 to the dsPIC. When you were ready to either debug or run the firmware, you would set the switches on the shield to connect the I2C interface to the board.
Best regards,
Bill
Also having looked at the data sheet of the dsPIC fitted to the UAVDevboard I believe the pins for the hardware I2C unit could be used via the ICD2 header, however this would remove the ability to use the ICD2 as a debugger and I havn't looked into it in great detail.
This would allow an magnetometer / compass module to be attached to the board along with other I2C elements such as the open servo.
it adds a whole bunch of new facets and options
Well Done