Replies to This Discussion

Permalink Reply by Garth on August 22, 2009 at 10:49am

Good Thinking Belli Button
it adds a whole bunch of new facets and options

Well Done

• ▶ Reply

Permalink Reply by Mostly Procastinating on August 22, 2009 at 11:11am

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.

• ▶ Reply

Permalink Reply by Belli Button on August 22, 2009 at 1:41pm

Hi MP,

This board would not require I2C or the use of the debug header or anything else. I'll post it tomorrow and chaps can comment on it. I don't think a magnetometer/compass is necessary with Dr. P's excellent design. It would place a little more load on the CPU but currrently only 4% of its capacity is being used.

I would like to add Ublox to the UAVDev board but that is still a little bit away.

• ▶ Reply

ModeratorPermalink Reply by Chris Anderson on August 22, 2009 at 2:28pm

Yes, with a 4-5Hz GPS, a magnetometer is not needed. The only reason you'd want want would be for indoors or hovering (heli) use.

• ▶ Reply

Permalink Reply by Mostly Procastinating on August 22, 2009 at 4:05pm

Indeed, just just drawing attention to what may or may not be possible within the hardware restrictions of the UAV DEVboard.

I wonder if Bill Premerlani or anybody else has any views on the viability of using the I2C connection as a possible expansion port?

As befitting my user name my UAV board is currently a rather attractive yet under utilised paper weight...

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on August 22, 2009 at 6:16pm

Mostly Procrastinating:

Just remember, its the "early bird who catches the worm", but its the "second mouse who gets the cheese."

I think what you are doing is waiting for me to finish the firmware to your satisfaction.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Mostly Procastinating on August 25, 2009 at 4:36pm

Bill

Sorry it has taken me a while to reply to this, just wanted to compose my answer a touch before I started typing.

"Just remember, its the "early bird who catches the worm", but its the "second mouse who gets the cheese.""

Its a good saying that I have never heard before and can think of many examples of when this would be true, I will certainley remember it for future reference....

"I think what you are doing is waiting for me to finish the firmware to your satisfaction."

I'm abit unsure of how you came to this conclusion, it is far from my goals and intentions and if this post appears a touch wary its beacause I don't wish to make you further supsicous about my motives so I will lay me goals and motivations plain.

My main goal is to improve my maths and programming skills by fully understanding the background to the DCM theory.

I want to do this primarily using the UAVDevboard (which I have purchased) to update a on screen display of the orentaion of the board in a program yet to be decided.

Once I have fully understood the underlying maths and programming and dsPIC architecture I want to combine this into a air frame and step towards a full UAV.

At the moment I don't have a radio control airplane or the skills to fly one, hence my interest in incorporating a magnometer or compass module to provide the reference vector to correct the DCM matrix as opposed to the GPS reference provided in the firmware.

Once this milestone is acheived I want to then prograss to flying my PICDev board IMU with wireless downlink (read Xbee) in a easy star while learning to fly and then progress from there.

With regard to the choice of GUI software to display the board orientation I am torn between microsoft C# and the python language used by Brian Wolfe and others.

I feel that python may be the superiour language but the ardupilot ground station is written in C# and I want any work I do to be accessible to the UAV community at large.

Any input yourself or other have on this matter would be warmly welcomed....

I aplogise (spelling I know.. :( ) for the rambling nature of this post but I wanted to set the record straight about my intentions.

An work I successfully complete will of course be made open source in the spirit of this site.

Kind Regards,

MP

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on August 25, 2009 at 5:09pm

MP

I was making a joke when I said:

"I think what you are doing is waiting for me to finish the firmware to your satisfaction."

;-)

I think your plan is a good one.

The only input that I have is that you should definitely learn to fly manually before doing any UAV development test flights of your own. The EasyStar is a good way to get started. You could use your UAV DevBoard in the EasyStar, running MatrixNav, to make it even easier to fly, and to provide a return to launch function.

Best regards,
Bill

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on August 22, 2009 at 6:30pm

Belli,

It would be easy to add a Ublox to the DevBoard. The hard part would be getting a Ublox.

To add a Ublox, you would need Jordi's Ublox adapter. (Thank you for that, Jordi!) You would also need to write the firmware to communicate with the Ublox.

Billy

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on August 22, 2009 at 6:14pm

Hi everybody,

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

• ▶ Reply

DeveloperPermalink Reply by Doug Weibel on August 22, 2009 at 7:26pm

Hi Bill and all,

As a RC heli guy I can tell you that proper mounting of a gyro to isolate it from vibration is critical for good performand, so I am not surprised you have found a similar need to consider how the DevBoard is mounted in the airframe.

I am no expert, but I can tell you that in general heli guys use a special 2 sided foam tape to mount gyros, and not just any 2 sided foam tape. Some are much better than others. You can get good stuff from a RC heli shop. Stuff intended for mounting gyros in nitro heli's is the best. Another trick for even better isolation is to take a piece of thin aluminum. Mount the gyro to the aluminum with one piece of foam tape, and mount the aluminum to the airframe with a second. Having the aluminum layer is much better than just doubling the thickness of the foam tape.

Doug

• ▶ Reply

Permalink Reply by Belli Button on August 23, 2009 at 12:00am

Hi Bill,

My board uses only two of the CCP modules to read all eight channels. This happens by virtue of the fact that the receiver sends the channels one frame at a time. One input could be used to read all eight but it would be complex to differentiate between the different frames as there is no separator (time delay) on my receiver. Instead I 'OR' the 1st, 3rd, 5th and 7th channels to the first input CCP and the 2nd, 4th, 6th and 8th to the second CCP. The CCP module waits for a an extended frame period which marks the beginning of the new set and then measures the first frame on channel one. The second CCP measures the second frame on channel two while the first saves the data and prepares for the third frame, etc, etc. When the eight frame has been read there is a delay from the receiver to mark the begining of the new frame set and the cycle repeats.

This would leave the third and fourth CCP's open to use as analogue inputs for additional sensors. Airspeed and altitude are the two that come to mind but they could be anything. The analogue signal is converted into a PWM signal which can still be read by the CCP module as before and the value saved where appropriate. The code changes I think will not be extensive and the interrupts are generated at the same speed as before.

Is my thinking correct? Naturally if you want eight input channels you need a nine channel receiver, if you want less then you would need only n+1 channel receiver.

The outputs are multiplexed with a '2 to 4' decoder, two lines select which channel you are sending and the third line sends the frame. If you steal one other output line you could extend you output channels to eight but then the board would not be able to plug directly below the existing pin headers.

For U-blox integration I have brought 5V and 3.3V to a header where the EM406 plug would normally be on my board.

Cheers,

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page