FANDOM


https://groups.google.com/group/uavdevboard-dev/browse_thread/thread/66dd3db5feeed981

  - Clean data from the ultrasound
  - revise range data to account for bank and roll (fairly easy) (i.e.
  determine vertical range to ground).
  - The system, with no "look ahead", is only really suitable for flat
  landing fields.
  - Feedforward control, understanding the characterstics of the plane
  close to stall, along with drag characterstics, may be vital.
  - Good landing may require a good understanding of the "transfer
  function" of the plane for pitch control, but since we are operating close
  to the stall, the mathematical model may be invalid.

notes Edit

- Ensure we have frequent and accurate trustworthy data from the Sonar
  Height Above Ground sensor.
     - We may need an "observer" style Kalman Filter, in order to get
     quality data.
     - Raw data is only fed 10 times / second from Sonar.
     - At 10.0 m/s and 20 degree pitch down, the plane is descending at
     least at 3.4 m/s. If the beam is working at up to 7 meters from ground,
     then that provides a valid return from 7.0 * cos(20), which is 6.5 meters
     above ground. In other words, the flare must occur within about

1 second of

     flight, in order to flare safely, 1 second before hitting the

ground ! Not

     much room for an error margin. Of course those figures improve if the
     intial descent rate is less thatn 20 degrees.
     - The entire concept of downward looking Sonar implies the landing
     site is flat, or gently sloping. Sudden changes in slope will not be
     detected in time.
     - We probably need our plane's to be optimally set up for control of
  height by the AutoPilot. The best way to do that, is to learn how Bill has
  extracted the control Transfer Functions for Pitch and Roll from his Quad,
  and apply that type of technology to pitch control, and height control of
  the plane. Then, with transfer function in hand, we can model the entire
  flare control algorithm in a mathematical simulator like the Open

SourceXcos<http://www.scilab.org/products/xcos>(similar to Simulink for MatLab).

  - Only once we have successfully modelled the landing in Xcos, with
  typical noise to the Sonar, would I really want to embark on coding up the
  solution. I enclose a sample (made up), options.h entry for Sonar Flare and
  Landing.

//////////////////////////////////////////////////////////////////////////////// // MAXBOTIX SONAR TERRAIN FOLLOWING AND LANDING FLARE // Designed for use with the following device:- // http://www.maxbotix.com/Ultrasonic_Sensors/MB1230.htm // Can be used on INPUT 8 of the UDB4 if that is not used for other purposes. // Will compensate for roll / pitch, subject to receiving a returned sonar signal. // // This option is for UDB4 only // Height is returned 4 times / second in centimers in SERIAL_UDB_EXTRA PWM channel 8. //

// NOTE: Requires Auto Pitch PID adjustment to be enabled. // Auto Pitch PID will auto adjust your plane for the best possible PID control of height.

  1. define AUTO_ADJUST_PITCH_PID 1

// SONAR_STABILIZED_TERRAIN_FOLLOWING // In stabilized mode, the plane will attempt to stay above a minimum sonar height from ground // using Throttle and Pitch. If Throttle is cut to zero, the plane will glide in.

  1. define SONAR_STABILIZED_TERRAIN_FOLLOWING 1
  2. define SONAR_STABILIZED_MINIMUM_HEIGHT 2.0 // Meters. Minimum

1.0, Maximum 6.0

// SONAR LANDING FLARE

  1. define SONAR_LANDING_FLARE 0
  2. define SONAR_FLARE_DESCENT_RATE 0.3 // Meters / Second. 0.3 is

default value.

  1. define SONAR_FLARE_START_HEIGHT 4.0 // Meters. Minimum 1.0, Maximum

6.0. Start High !

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.