On Sun, 2002-11-10 at 20:33, Thomas J. Williams wrote: > 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's OK, we are all geeks here. Terse is actually viewed positively most of the time. > 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 > Reasonable simplification. > 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). > Only as long as we can ensure sufficient runtime speed and size. > 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 �). > Some of the tradeoffs that need to be made are between redundancy and weight. The likelihood of the sensor failing versus how much weight and complexity a rendundant sensor costs. For Gizmo we will be using only gyros and accelerometers, without redundancy. The reliability is sufficiently good and the flight profile sufficiently benign that there is no need for redundant systems. For POGO the addition of redundant accelerometers and a DGPS system would be beneficial. If POGO was not en evolutionary step towards a sub-orbital and orbital vehicles, then the DGPS would be a waste. This step is actually one of the more difficult parts and I am researching carefully. The problems are determining which sensors are providing valid inputs and doing the appropriate rotational sequences. There are filtering algorithms for getting the sensor inputs right (or at least close enough), and I am trying to get my puny brain wrapped around them. Then comes the rotational sequences, which need to do in conjunction with determing the current vectors. > 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. > We are starting off with stability augmentation, progressing to command augmentation, and (maybe?) ending up with autonomous control. So at first this step is straightforward, just get the joystick position. > Step 3 you have already with your Quaternion and math library. > Actually this step should be done with 1. above. Some of the sensors are linear and some are rotational, so we need the rotations to get the right information from the linear sensors. > 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). <snip> This is the other tough step, and yeah. > > 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%)? > Actually the latency of control application is not all that major.A rough idea of it is good enough. The Proprtional-Integral-Derivative control algorithm actually makes up for latency in the integral and derivative terms. The trick is getting the constants for each term fairly close, then tweaking them based on observed behavior. (There is a proven method for determining the constants mathematically, but it is not a simple process, and experience shows that starting with a rule of thumb estimate and tweaking gives as good or better results anyway.) > 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. > We are trying to keep to this type of division of code, but there are costs in terms of binary executable size and execution time that need consideration, so nice clean breaks by doing APIs and function calls can be difficult. But code is much easier to maintain when broken up, so we do what we can. Dave _______________________________________________ ERPS-list mailing list [EMAIL PROTECTED] http://lists.erps.org/mailman/listinfo/erps-list
