Talk:Software Wish List

Flight Plan Interpreter

A flight plan interpreter has a lot of advantages and disadvantages. As seen at the recent Army demo the ability to add waypoints and change flight modes (go, loiter, land) was a huge advantage to the end user. However it has been discussed that doing an interpreter will cause some of the unique and powerful features of the flight plan code to go away. The extent of this is not yet realized. This page will help track the progress as well as the end vision for the interpreter.

Lets start with what we will gain from having an interpreter.

• Adding waypoints for points of interest.
• Changing mode during waypoint(go,route,circle,land).
• Change altitude for mode and even schedule altitude changes.
• Change radius, camera angle, or camera mode.

Now what will we lose from having an interpreter.

• No ideas here!

Discussion

• Now lets talk about what we could do here. Antoine and Pascal, what sort of time frame are we talking about for something like this. Can you estimate what we would lose with the interpreter. Any thought you have on this would be great. Add it to the bottom of this page like I have here.

- Anton

• What do we need exactly? The requirements cited above (Change radius, camera angle, altitude ...) looks like only some parameter modifications of an existing flight plan. Do we need:

  change of parameters of the current stage?

  change of parameters of any stage (how to name it?)

  change of some specific "dynamic" named stages?

  replace or add of a new block?

  replace of the whole flight plan (including the waypoints)?

• How would the autopilot switch from its current flight plan to the new one?
• Note that most of these features require some dynamic memory allocation (to store the new flight plan), something we always wanted to avoid in airborne code.

- Pascal

• I think the biggest thing that is needed is the addition of points of interest. And the ability to say, Lets fly a square around these 4 points click, click, click, click 4 waypoints created, lines between them to show direction, or let the camera angle dictate the direction, and send. then maybe adding a waypoint and say circle here altitude of 100m, radius of 100m, and camera point to center. Pretty much it would be defining a new flight plan, in a graphic sort of way. I think the idea would be if someone asked can you circle this, or loiter that at this altitude or this radius you could do it without saying "well Id have to land because I didnt program it to do that" Im imagining that this feature is a lot of work, mainly because it wasnt done in the beginning, and for large very structured UAVs the method used now is good, but for MAVs, which are supposed to be deployed at a moments notice, its of high priority to get airborne in a hurry, and then build the plan while airborne. At least thats what I envisioned. Although maybe Jeremy shoudl chime in on this, altitude and radius should be linked due to the camera position I woudl think. I know Im rambling but Im just thinking out loud.

• Why did you want to avoid dynamic memory allocation?

- Anton

• I agree with avoiding dynamic memory allocation - we'll reserve that for the gumstix which has a priviledge mechanism - we absolutely want to avoid that the upload of a bad flight plan crashes the ap. We want the airplane to be able to go home in case something bad happens in the navigation.
• So I vote something very basic and very hardwired. This will probably fit 90% of the use cases.
• What about making the "interpreter" a block of a flight plan writen with the current compiled langage ?

We could release to users with a default flight plan containing the interpreter block and a number of compiled procedures available from it (like the loiter procedure ). The waypoints could be "uploaded" before flight, maybe home could be auto-guessed ( and not changeable aftertake off ) and a default configuration done at takeoff ( put the first 4 waypoints nort south west east at 200m from home, circle north waypoint ) if home moved alot ( do we have eeprom finally ? ). Then the user could upload data ( not code ), like waypoint coordinates like we already do, but also type of navigation. We forget about doing tests in here - the interpreter block code can of course perform tests ( like what to do on low battery), but this mechanism won't be updated in flight.
- Poine

• The ability to add waypoints within a path is a must. If its doing a route around 4 points and you want to add a 5th I think this is most crucial. Loitering isnt such a big deal, but possibly the test conditions are. Like you may select 3 points, and say go loiter here for 3 minutes then over here for 5 and over here for 5, all the while there needs to be a test running all the time that has a relationship between battery voltage and dist2_to_landing_point or something. This test should give confirmation if the waypoint in question is outside this condition. And allow the user to choose, meaning choose to get the information and sacrifice the airframe.

- Anton

• In my opinion you should leave the dynamic memory allocation away. You'd rather use fixed length arrays. That's the way it is done in operating systems. Especially you avoid fragmentation problems this way. Malloc would returns an error if the bloc you want to allocate is too big. You can also very efficiently test for out of bound access.
• Also you can define read only zones in the tables which are reserved for security procedures, like return home. The home waypoints and blocks should not be writeable from the uplink. This way you can check before start that the waypoints are in a reasonable range, in flight that new waypoints are valid. (It looks like a bootloader somehow: a part of the waypoint table is not writeable from the upklink interface)

- Martial