I updated the message when you select AUTO mode but you haven't put
any waypoints in. It now says "No commands so can't set AUTO- setting
HOLD instead"
This removes a lot of the ArduPlane specific cruft left over from the
initial Rover import from ArduPlane, plus fixes a bunch of serious
bugs. For example, the rover was unable to use either compass or gps
for heading - it used just gyros!
There is still a lot of cruft left, but this at least gives a bit
better basis for future work
Added option (hold roll to full right + SW7 ON/OFF) to init_home during the wp_list reset
Add ROV_SONAR_TRIG (default = 200 cm) - tested by Franco
Restart_nav() added and heading bug correction, tested OK in the field
RTL then stop update - Tested OK in the field
Added SONAR detection for obstacle avoidance
Signed-off-by: Jean-Louis Naudin <jlnaudin@gmail.com>
when we are in the final stages of a landing (less than 2 seconds from
landing waypoint, or less than 3m above landing altitude) we switch
the navigation to use a fixed course. The code previously used the
crosstrack_bearing for this, but this can lead to a large nav_roll in
this final stage of the approach, which can put a wing into the
runway. In autotest we were seeing a nav_roll value of -45 degrees as
we crossed the transition point for the landing, which often led to a
crash.
This changes the code to use the current yaw_sensor value instead,
which is much less likely to lead to large rolls in the final landing
stages.
hold_course is either -1 (for disabled) or a course to hold for
takeoff/landing. This makes the code a bit clearer.
It also resets hold_course in all non-auto modes, to ensure it isn't
used
If you include airspeed, throttle or groundspeed changes in a mission
then those should not be saved to EEPROM, as otherwise if you restart
and re-fly the mission you will be starting with different parameters
to the ones you used for the first flight.
This is particularly important for setting the target airspeed when
coming in for a landing. You typically set a low target, but if you
fly again the next day I think it would be a real surprise to find
that your loiter airspeed has then changed to the value from the
landing part of your last mission.
This one can be argued either way, but I think that not saving these
changes is the more conservative choice, and better fits the
'principal of least surprise'
This patch will boost the target airspeed as necessary to keep the ground speed above a parameter value - param_min_groundspeed. Airspeed is still limited to FBW-max. Setting min_groundspeed to zero (default) disables the feature.
It is fully configurable with the mission planner, there is no need to change
the source code to adapt to your setup.
It needs more testing, but the SIL is not working for me.