I'm part of a group that is also currently trying to stabilize a helicopter using your dev board.
As of now, we are using the ADC converter to convert the analog voltages from the accelerometers/gyros on the board. Looking at the roll-pitch-yaw demo, if i'm not mistaken, you're using the 16MHz HS clock, meaning that FCY = 4MHz, and looking at ADCON3, TAD = 32 * TCY = 8 microseconds, which means that we're sampling at 1/TCY = 125kHz... Is that accurate?
Furthermore, we've been collecting the first 1000 samples and averaging them to create offsets that are subtracted from each value to zero out the accelerometers and gyroscopes. In order to see what we're doing, we've been outputting everything on the serial interface using a baud rate of 19200, which, appears to be the maximum baud rate possible for our clock frequency of 4MHz. That baud rate was chosen to try to keep up with the conversion rate.
I suppose what i'm asking is, whether there's a better way to monitor our data. For every ADC interrupt, we collect samples, zero them, and dump them out on the serial. I had initially thought that these computations weren't too much overhead, but i'm not so sure about that anymore, since the output seemed to slow dramatically when i tried to output the integers coming out of the ADC as floats (double) using sprintf and snprintf. Whether this is slowed down because sprintf is slow or because we're now working with floats instead of integers I am not sure. The data we've been seeing on the serial is also pretty noisy, and we're wondering whether or not it's the conversion rate, the serial interface, or a combination of both that is contributing to this.
I apologize in advance if this is too much information at once.
Thank you very much,
Matthew Lim
Carnegie Mellon University
Class of 2009 (undergrad)
You mentioned that you and Paul were doing some simulations with the new R Matrix approach. Can I ask what kind of simulations are being done? Hardware-In-Loop? Test cases? Parametric studies? Obviously an important step since this technique may well go beyond "gentle" corrections to full-blown 3D maneuvers (which I think is one of your goals). I saw something on ArduPilot where they actually interfaced the controller to a flight simulation program (X Plane I think). Do you have any plan for a simulation test-bed that could be used with a variety of platforms, using at least representative aerodynamic characteristics? That could be something that others in the community could contribute to, probably drawing on ArduPilot work as well.
I know this is a stretch, but is it out of the question to use this to stabilize a Heli with 3 servo CPPM? The hardware seem capable....the correct sensors and plenty of compute power.
Your roll-pitch-yaw demo is absolutely excellent!! I was wondering if might be able to post a video showing the board moving in conjunction with the servo output? Do you have an estimate of when the paper discussing the theory and math will be available?
Hi Bill
Great work this project has me hooked,
i have a few questions regarding more the GPS side of things
How do you program "way points" or a pre determined flight path and in what language
is that programming stored on the GPS module or on the main board
Just out of curiousity, I do not quite follow the choice of the external 16MHz clock. In essence this means if you are using the HS setting in FOSC your CPU will be clocked with 4MHz (FCY == FOSC / 4). So your only real choice to get decent CPU performance is to use FRC w/PLL x16. In which case of course you'd loose the precision of having an external crystal ...
if you can stuff these calculations into compact and efficient code then i'm sure world will beat the path to your door for this software. do you have a timeline for this?
As far as i know most modern EFIS suites use gyros and acceleromenters to calculate pitch roll and heading (along with vertical and horizontal speed) but stabilize what they get using gps and magnetometer information. is this exactly what you are working on now?
Gentlemen,
Congratulations !!!
What you have achieved here is incredible!
Sure, it's been done before... but not in civilian laboratories.
Back in the 1980's, I was tasked to build a 3 axis IMU from the existing Copperhead missiles' roll rate sensor.
The unit had a Coriolis effect rate sensor and an accelerometer for each axis. The mission was to provide data to a flight controller for an ejection seat system, controlling a gimbal mounted rocket motor for propulsion.
The unit was able to turn on and provide calibrated data within 140 mS. It had a maximum angular rate of 3000 degrees per second and an acceleration limit of > 2000 G. However, the unit was 4" cubed and weighed ~ 1.8 pounds. It consumed ~ 5 watts of electrical power!!!
Replies
I'm part of a group that is also currently trying to stabilize a helicopter using your dev board.
As of now, we are using the ADC converter to convert the analog voltages from the accelerometers/gyros on the board. Looking at the roll-pitch-yaw demo, if i'm not mistaken, you're using the 16MHz HS clock, meaning that FCY = 4MHz, and looking at ADCON3, TAD = 32 * TCY = 8 microseconds, which means that we're sampling at 1/TCY = 125kHz... Is that accurate?
Furthermore, we've been collecting the first 1000 samples and averaging them to create offsets that are subtracted from each value to zero out the accelerometers and gyroscopes. In order to see what we're doing, we've been outputting everything on the serial interface using a baud rate of 19200, which, appears to be the maximum baud rate possible for our clock frequency of 4MHz. That baud rate was chosen to try to keep up with the conversion rate.
I suppose what i'm asking is, whether there's a better way to monitor our data. For every ADC interrupt, we collect samples, zero them, and dump them out on the serial. I had initially thought that these computations weren't too much overhead, but i'm not so sure about that anymore, since the output seemed to slow dramatically when i tried to output the integers coming out of the ADC as floats (double) using sprintf and snprintf. Whether this is slowed down because sprintf is slow or because we're now working with floats instead of integers I am not sure. The data we've been seeing on the serial is also pretty noisy, and we're wondering whether or not it's the conversion rate, the serial interface, or a combination of both that is contributing to this.
I apologize in advance if this is too much information at once.
Thank you very much,
Matthew Lim
Carnegie Mellon University
Class of 2009 (undergrad)
You mentioned that you and Paul were doing some simulations with the new R Matrix approach. Can I ask what kind of simulations are being done? Hardware-In-Loop? Test cases? Parametric studies? Obviously an important step since this technique may well go beyond "gentle" corrections to full-blown 3D maneuvers (which I think is one of your goals). I saw something on ArduPilot where they actually interfaced the controller to a flight simulation program (X Plane I think). Do you have any plan for a simulation test-bed that could be used with a variety of platforms, using at least representative aerodynamic characteristics? That could be something that others in the community could contribute to, probably drawing on ArduPilot work as well.
Great work this project has me hooked,
i have a few questions regarding more the GPS side of things
How do you program "way points" or a pre determined flight path and in what language
is that programming stored on the GPS module or on the main board
Thanks
Congratulations !!!
What you have achieved here is incredible!
Sure, it's been done before... but not in civilian laboratories.
Back in the 1980's, I was tasked to build a 3 axis IMU from the existing Copperhead missiles' roll rate sensor.
The unit had a Coriolis effect rate sensor and an accelerometer for each axis. The mission was to provide data to a flight controller for an ejection seat system, controlling a gimbal mounted rocket motor for propulsion.
The unit was able to turn on and provide calibrated data within 140 mS. It had a maximum angular rate of 3000 degrees per second and an acceleration limit of > 2000 G. However, the unit was 4" cubed and weighed ~ 1.8 pounds. It consumed ~ 5 watts of electrical power!!!
We've come a long ways baby...
ROB
-
7
-
8
-
9
-
10
-
11
of 11 Next