You are right. I assumed (wrongly) that model UAVs would aim for photos etc.
I will be happy if the autopilot can fly a route accurately and hold height. I think that most model pilots over-estimate their bank angles (and their models speed!). What do you think about ignoring the frame difference if I accept a 10°/sec limit?
I hope to resolve the yaw and pitch rotation rates, mainly to correct the elevator in turns. And to use the lateral accelerometer to control the rudder. I've used many full-size autopilots that weren't that clever!. My UAV will have some stability, so I hope a gust won't tumble it right over!
Has anyone, experienced with this PIC30F4011, found a way to use the program memory to log data? The free data memory is too small. I'm playing with track keeping at the moment, and using the COG and SOG (from the gps SIRF message) is looking very promising. I would like to log some real data to measure gps accuracy. I'm using guesses of ± 5 meters on the positions, ± 5% SOG, and ± 2° COG at the moment.
1. Frame error effects and resolving pitch, yaw gyros.
2. Logging data to the program memory of the PIC30F4011.
I am going to address each topic in a separate discussion, starting with frame errors.
You are right, as long as the bank angle is not too large, the frame error between the body and earth frame of reference is not so large as to cause a problem. I have been flying a Gentle Lady using the "GentleNav" firmware available on this website for a couple of years.
When I started out, I was concerned about the effects of bank angle, and worked out a way to mix rudder-elevator and to decouple pitch-yaw gyro based on the bank angle. The problem was, I did not have any direct estimate of the bank angle, so I had to compute it indirectly. I did make some progress in that direction, but I realized to get it working well, I would have to use a rather eleborate model of the dynamics of my sailplane. In the end, I decided it would be easier to simply limit the turning rate and bank angle. That is what I am using now, it works just fine.
It limite the turning rate and completely ignores the bank angle. It treats rudder and elevator control completely independently. Rudder is controlled by yaw gyro and GPS. Elevator is controlled by pitch gyro and accelerometer. There is no rudder-elevator mixing and no attempt to adjust for cross coupling of pitch and yaw gyro information. However, the sailplane speeds up through any turns.
I think you could slightly extend the "GentleNav" firmware to control speed and altitude, although that would be a somewhat of an underutilization of the resources of my new board, since it used only 2 gyros and 1 accelerometer.
Better yet, I am sure that you could do very well by using all three gyros and accelerometers and start from scratch on the control/navigation portions of the firmware.
By the way, Paul Bizard is working with me on an algorithm to combine gyro, accelerometer, and GPS information into a fast, accurate, stable estimation of the orientation of the plane. Implementation should be a natural fit to the architecture of the dsPIC30F4011. It is a work in progress. We have made several improvements and refinements to our original idea. Right now the algorithm is being simulated by Paul, who is doing all the work. As soon as we have something that we are satisfied with, we will publish it here, and I will get started on implementation.
Regarding using the program memory of the dsPIC30F4011 to store data:
I have never done it myself. However, from the documentation for the PIC, it should be possible, though it would be cumbersome. Take a look under the section on "Flash Program Memory" in the PIC documentation.
Logging to the program memory on the fly is similar to programming the EEPROM, which I have done. You first erase a "row" of the memory, you write to the row, and then you program. You do not have to actually do the erase on the fly, you can do that by erasing the entire memory before you load your program in the first place.
After you read the data, presumably through a programmer/debugger, you could erase it prior to the next flight.
Be aware that the CPU will "stall" for 2 milliseconds for each 92 byte row of memory that you program. The good news is that all of the important hardware resources will continue to run, such as the A/D, the USART, the PWM outputs, the capture inputs, and timers. The bad news is that 2 milliseconds will get added to the latency of processing interrupts. In the case of the A/D converter, you will lose a few samples, but that does not matter. For the USART, the 4 deep buffer should keep you from losing any data from the GPS, but you will have to be careful in the USART interrupt handler to consider the possibility of several bytes arriving since the last interrupt. You may miss a couple of capture interrupts, the worst thing would be that manual control would skip one pulse, you would not even notice it.
Also be aware that if you are not careful, you could wind up writing over your program, in which case you could lose control of your plane entirely. So, if you decide to log data to program space, it would be best to do thorough pre-flight testing.
I would guess from your question that you might have my board, in which case you also have the option of connecting a separate memory board with a serial interface to the spare USART
I had a couple more thoughts about using program memory of the dsPIC30F4011 to log data. It might be easier than I said in my previous comment.
According to the documentation, you can use either program space visibility, or table read/write registers to do read/writes to program memory. I have used program space visibility to read program memory and I have used the table read/write registers to program the EEPROM. The point is, the program space visibility is a lot easier to use, it will map 16K words of program space to 32K bytes of data space.
The documentation is not clear about when, if ever, the flash program step needs to be made in order to read back data that was written to program space. Possibly, the only function of the program step is to make the data non-volatile. It would be better not to do the program step during flight, to avoid any "glitches" during the 2 millisecond CPU stalls. So, there might be a simple, "glitchless", transparent option:
Use the program space visibility feature to access a portion of program space as a log buffer. If you want the log to become non-volatile, execute the programming at the end of the mission. Otherwise, use the spare USART at the end of the mission to read it out before powering down.
The only complication that I see is that the C compiler will probably not let you write to a variable that is mapped into program space, so you might have to write an assembly routine to do the logging. Also, it might be that you have to actually commit the data to memory by programming it before you can read it back.
You might want to do some experiments to check these ideas out. When I have some time, I will too.
Well, it is not as easy as I thought it might be to save data to program memory. I tried a few things and read more documentation. It is not possible to simply treat the program memory as if it were data memory. Wishful thinking on my part.
It is possible to store data to program memory, but you will have to first write data to a 92 byte "panel" latch using table write instructions, then program the panel into the memory, which will stall the CPU for 2 milliseconds.
The compiler will give you some help. Declare a constant array and initialize at least one element. As a result, the compiler will allocate the array to program space and at least allow you to read it using C statements.
Well, Paul and I are making definite progress. I just finished a roll-pitch demo that suggests that it is possible to stuff these calculations into compact and efficient code. It looks like maintaining the direction cosine matrix will be easy enough to do, and will provide smooth, accurate, fast response.
Take a look at a discussion on the subject that I just started.
I couldn't find enough information from the eagletreesystems website to answer your question for sure, but I do not think it would be easy to interface my autopilot board with the sensors from Eagle Tree Systems. It looks to me that what they have is a data logging system, without a published interface. Perhaps someone else reading this can give you a more definitive answer.
Also, I believe that if you use my board, you really will not need altitude or airspeed sensors, if you use an IMU based "direction cosine" estimator that takes raw gyro, accelerometer, and GPS information and combines it to form an orietation estimate. (For more information, see my discussion of the "Rmatrix".) Paul Bizard and I are presently working on theory, simulations, and implementations. I have implemented most of it, and have measured astonishing accuracy (less than 1 degree error), fast transient response (0.020 seconds), and zero drift. What I have implemented so far is a nonlinear, rotation-group based integrator of the gyro signals, with a proportional+integral drift correction based on GPS and accelerometer. I took it for a stroll around the neighborhood, it is very precise, and locks on, drift and error free, at an average walking speed. Roll, yaw, and pitch estimates are right on the money.
Next, I plan to implement automatic gyro gain adjustments, so that I can put my plane into a continuous barrel roll without accumulating any roll error.
From there, I can see how I can combine orientation information with GPS Doppler-based velocity information, and GPS position, to achieve estimates of altitude and airspeed with an accuracy that is more than adequate to achieve altitude and airspeed hold. The reason that I believe I can do this, is because the orientation information is so accurate and drift-free, that I think that I can maintain separate, accurate estimates of ground speed and airspeed.
I plan to make the "direction cosine" firmware available in a few weeks. After that, I will continue to make refinements available here on a regular basis, and give updates on my plans.
By the way, it is easy to achieve altitude control with a direction-cosine, IMU-GPS based control without using additional sensors. Take advantage of the precise and fast orientation information to implement tight control of the pitch angle. Maintain power above the minimum value needed for control. Place a low gain outer loop around the pitch control, based on GPS altitude, to gently raise or lower the pitch angle to climb or descend. The low gain will filter out GPS variability, and respond to the average altitude. Use feed-forward to stabilize the airspeed: add power when climbing, and reduce it when descending.
Very informative reply, thanks!
I should have stated that one goal of my UAV is for air density research purposes so I really need the ability to capture barometric altitude. Perhaps the Eagle Tree microsensor system is not the best choice for a barometric sensor interface. So the real question is could a pressure transducer of any kind be interfaced for barometric altitude hold such as the Honeywell ASDX015A24R (http://www.onlinecomponents.com/product/3156863/)?
Also, I am thinking about adding an angle of attack sensor and wonder if one could be interfaced?