Software Wish List

Please use the Discussion tab at the top of the page, as appropriate

Ground Station Suggestions

• Path interpreter
• Divide the flight plan into 3 separate files (Jeremy)

  Takeoff/Landing - flight plan blocks describing the complex routines and using altitudes and waypoints from the User file

  Generic - a file that users should never need to edit, containing circles, rectangles, figure-8's, and surveys that appear on command when GCS buttons are pressed. Altitude/locations could be relative to the User file

  User - Here we can specify fixed or dynamic Home point and add complex routines or simply save certain basic routines.

• How about the possibility to use multiple ground modem connected to a single ground station. The RSSI could be use to dynamically choose which currently has the best signal. This would alow the use of different antennas on each of the modems or have antenna pointing in different directions
• PFD - the horizon and the sky shouldn't move only the main line. Because we are on the ground and we really need to see the turn rate of the uav and not the real PFD like on a real airplane.

Airborne Software Suggestions

Navigation

• Flight plan stage sensing

  Carrot should continue past the waypoint toward the next point, but the point should not be officially acknowledged until the plane has passed it. This way we can have smooth, intelligent navigation while still considering waypoint triggers such as still-photo, sensor drop, or throttle off.

Other

• Revised autopilot modes (Jeremy)

  I propose a restructuring of the modes as follows - create 3 top-level modes: Man, Stab,and Auto, each with an appended autonomous sub-mode (i.e. Man/Climb, Stab/Kill, Auto/Landing, etc.) This will give the operator much more information and a much better indication of what the plane will do when switched to autonomous mode in a concise manner. Furthermore, I see an advantage in having simple behaviors like Climb, Landing, etc. be defined as sub-modes so that operator is always alerted of changes such as Descent or can easily configure trim, gains, and payload options in the airframe file (i.e. if mode = Landing then retract camera, turn off video system, use landing trim, etc.)

  • Sub-modes
  1. Ground - The default boot mode. In this mode the throttle is locked at 0% or not armed at all (no PWM signal), stability is disabled (servos locked in neutral position), and video power is off, but flight plan blocks are processed. This will improve safety and aid in lost plane retreival as the servos, and video will not drain the battery if landing detection is implemented. Ground mode should exit only if Takeoff is manually triggered.
  2. Takeoff - 3 possible triggers: GCS button, GPIO button, or R/C throttle. Checks for error modes and desired climb, then arms/unlocks throttle, initates "Takeoff" flight plan block, and instantly deroutes to Climb mode. Deroutes to Descent mode without unlocking throttle if not OK. Takeoff could simply be a flag rather than a "mode".
  3. Climb - Triggered anytime "aggressive climb" is active
  4. Descent - Triggered anytime "aggressive descent" is active
  5. Nav - Normal level flight
  6. Landing - Same as Nav but using the "Landing" flight plan block and any airframe gains/trims/payload options as defined in airframe.xml
  7. Kill - Triggered manually - locks throttle at 0% and uses pitch/roll settings from Airframe.xml.
  • Error sub-modes
  1. No GPS - A temporary mode using pitch/roll settings from airframe.xml
  2. Home - Triggered by distance in Auto mode or by distance/RC loss in Stab mode (after n seconds, as defined in airframe.xml). Exits upon manual block/mode change requests from the GCS and cannot be re-initiated for 30 seconds.

• Continually broadcast last known location

  AP should continue to broadcast the last known GPS coordinate in the event of GPS loss. (i.e. upside-down crashed plane should continue to send last known position in case it was out of data range prior to the crash.)