Folks, I thought I might jot down some ideas after looking at the OpenVTVL flight software. The hardest part of putting together this mail is trying to keep it short, but without sounding terse or pompous, hopefully I haven�t failed at both too badly.
It seems like the solution breaks down into a couple of steps (disregarding things like initialization, telemetry, etc.). 1) Determine what the current Vector based on sensor inputs 2) Get the Desired Vector from the flight director software 3) Figure out the Vector that will transform the Current Vector to the Desired Vector 4) Determine what adjustments need to be made to the vehicle controls to implement the transformation vector 5) Make the adjustments to the vehicle controls It seems like one should make the software that performs each of the steps a component that could be updated/evolved independently of the rest of the software. (Via a function call, API, object or what-ever). The first step (get current vector from sensors) gets interesting when interesting when you start considering various failure scenarios (if you lose a sensor may be able to get somewhat equivalent data from other sensors, or possibly a backup sensor). For example if you loose the GPS, you can use dead reckoning based on last known position. You should be able to localize the software here that decides which sensor input to use to obtain the information needed to fly the vehicle. An important characteristic of the sensor software is that it should be designed to allow for additional sensors and sensors of new types to be added with a minimum of impact to the rest of the flight control software. If you lay the groundwork now, it will help as you evolve the software to handle more and more sophisticated hardware (Gizmo, to Pogo, to Spike, to �). I imagine the second step (get desired vector from flight control software) would be a component where you could substitute control directly from a pilot, or auto-pilot software, or possibly a combination where the input of a pilot is filtered through an allowable flight envelope (e.g. early flights may not allow for deviation vertical of more then X degrees, or velocity of V, etc.). But what-ever the flight direction software is, the software that performs step 2 shouldn�t need to change as the external control software is changed. Step 3 you have already with your Quaternion and math library. Step 4 (determine what controls need to be adjusted to implement transform vector) seems really interesting and maybe tightly coupled enough that it should be combined with step 5 (applying flight control changes to vehicle). It seems like you could need a fair amount of intelligence here but crafted tight enough to stay within your overall time/performance budget (doesn�t help to come up with the perfect decision on what to do too late to keep you from falling from the sky). As the environment and vehicle changes during the flight, it seems that the amount of control for the vehicle may need to change also. For instance as the flight progresses and you burn off fuel, you need incrementally less throttle to increase (or decrease) the velocity along your Z axis. Other similar circumstances may need to be accounted for like aerodynamic controls have different effects at various pressures (speed/altitude). I�ve also seen discussions on the list about the use of arrays of engines having the advantage of a greater margin of safety should you loose and engine. It seems that this would be the area of the software that would need to compensate for which of the vehicle�s maneuvering resources are available when trying to make the vehicle follow the pilot�s input. From what I�ve seen of the Gizmo-copter, I don�t think that it has an engine out capability, but at least the software could be crafted and tested for the time when there is more capable/redundant hardware. (I really like the array of smaller engine concept that you have discussed for some of the vehicles). It would also be important to understand the latency time between when a control is applied (in step 5) to when the expected action on the vehicle occurs. I was wondering if anyone has checked yet on the Gizmo copter to see if the �spin up� rate for the propellers is the same as the �spin down� rate. Also does it change at different levels of throttle (is it the same going from 10% to 20% throttle as it is going from 80% to 90%)? Theoretically this type of component software architecture could also help divide up the work/responsibility of your development group as well as defining the roles of the software components. Hopefully this has had some useful ideas/information. I work as a software architect for Bell Labs (at least as long as Lucent stays afloat), so I am much more comfortable with telecommunications software systems then flight control systems so please forgive any naivet�. I really enjoy reading about your experiences. -Tom Williams _______________________________________________ ERPS-list mailing list [EMAIL PROTECTED] http://lists.erps.org/mailman/listinfo/erps-list
