Are you a Ham? "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 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 -- >>>>>>>>>>>>>>>>----<<<<<<<<<<<<<<<<< ........ Alex Fraser N3DER ......... ......... [EMAIL PROTECTED] ....... [~]_>^</\-[~]_>^</\-[~]_>^</\-[~]_>^< _______________________________________________ ERPS-list mailing list [EMAIL PROTECTED] http://lists.erps.org/mailman/listinfo/erps-list
