The firmware that I will be developing will be mainly focused on assisting novice RC pilots to stabilize their aerobatic planes. Personally, I am not very good at flying model airplanes, so stabilization will be very important to me. In the near future, I plan to release firmware with three operating modes, manual, stabilized, and return to launch. So, the short answer to your question is, there are no way points.
My intent is that anyone who is interested in way points and is a do-it-yourselfer could easily extend my firmware to handle way points. It would not be very hard.
Another possibility is for you to wait until my firmware gets ported to an Arduino. That would open it up to a larger portfolio of open source firmware.
I am confused on how and what languages are used to communicate between GPS module and CPU
Does the CPU read the GPS information in NMEA, SIRF binary or both?
Is there a section in your firmware where the NEMA language or SIRF language is converted into C or does C recognize the NEMA or SIRF language without conversion?
I am not proficient in C hence all the questions
Is there a specific page in your firmware i should look at where the GPS and CPU communicate
The firmware for my previous board used NMEA to communicate with the GPS. The firmware for my latest board uses SIRF binary, which is definitely the better way to do it, there is more information available through the binary interface, and it is easier to implement a more efficient parser.
The parser is based on compiler parsing theory, and uses a state machine to do on-the-fly parsing of the GPS messages as they arrive, byte by byte, without the need for a full message buffer. Basically, you just need to figure out where to put the bytes.
Actually, it is not out of the question to use this to stabilize a Heli. Lately, I have been wondering the same thing, because the roll-pitch-yaw demo demonstrated incredible performance. I knew that the roll-pitch performance would be great, but the yaw performance was better than I expected, even when there was no forward motion.
So, yes, I definitely think it could be done. I would be happy to work with someone who would like to try to do it.
The biggest problem with helis is the pitch and roll axes. The rudder gyro does a fine job of stabilizing yaw. One of the complaints of the commercial system that I referenced earlier is that when you turn the gain of the system up high enough to lock in a stable hover, it fights you on forward flight (or any other pitch/roll commands). A better system would be to sense command inputs and mix into a final PID to the CCPM to stabilize to a new attitude.
I would be interested in working on this, but worry a little about the cost of the board.
(understandable given the sensor costs). Given that we are talking about a platform that can (will) hit the ground at terminal velocity, and there is no nice compartment to shield components, could go through a lot of expensive hardware.
Can the board be obtained without the gyros and accel if things go bad?
The ArduPilot with the IR sensors is cheaper, but the idea of a true IMU controller is pretty attractive for multiple platforms.
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.
You are correct, gravity vector is useless for yaw. I suggest the following two options:
1. Use the board for yaw stabilization only, without a GPS for yaw drift compensation. My recent tests with my roll-pitch-yaw demo indicates that the residual yaw drift of the direction cosine matrix algorithm without GPS, using the gyros that I am using, is about 1 degree per minute. So, you could use the board for a heading hold that would be rather stable.
2. Include a GPS for yaw drift compensation. My recent tests indicate that the direction cosine matrix algorithm would achieve lock, even with moderate (a few minutes) pauses in forward motion.
I believe the authors of this paper have the solution. They describe a method for integrating the nonlinear differential equations of the rotation group with both the kinematics and the dynamics of the aircraft. Basically, they explain how to integrate rotation measurement with control. So far, I have implemented only the rotation measurement. That is sufficient for airplanes.
For helicopters, and for the issues to mentioned, I think the next step is to implement the full measurement-control algorithm described in the paper.
If there is sufficient interest, it may be that SparkFun would come out with a board without the gyros. It is the gyros that are expensive, not the accelerometer.