- user defines a cone half angle which defines the RTL altitude behavior
- if vehicle is outside the cone it will climb until it intersects the cone
and then return at this altitude.
- if vehicle is inside the cone or above the predefined return altitude (RTL_RETURN_ALT)
then it will return at the current altitude
Signed-off-by: RomanBapst <bapstroman@gmail.com>
By declaring the params above the navigator modes inheriting from
mission block we make sure the params in navigator are set before
read in the constructor of mission block.
changed: "Mission rejected: land start required."
to: "Mission rejected: landing pattern required."
This new message is more clear to the average user. When using RTL_TYPE = 1, mission feasibility checker adds the requirement of a landing sequence beginning with a MAV_CMD_DO_LAND_START and ending with a MAV_CMD_NAV_LAND with at least 1 other waypoint prior to the land waypoint. The warning message "Mission rejected: land start required." is a common warning to trigger whenever the mission is blank or the mission is uploaded without a landing pattern. The wording in this message confusing to the average user as they usually do not know the inner workings of the "landing pattern" that their planning software helps them make (e.g. Qgroundcontrol). The only users who would know what a "Do_Land_Start" mission item is are advanced users already and this new message should work equally well for them as well as the non-advanced user.
- also applies to mission_stats_entry_s, mission_fence_point_s,
mission_save_point_s
- -Wpadded warning is disabled by default because the snapdragon
toolchain doesn't respect the pragma pop
* attitude and rate setpoint message: use 3D array for thrust demand
* FixedWingAttitudeControl: rework airspeed scaling
* move airspeed and scaling calculation into separate method
* if vtol in hover and airspeed disabled use minimum airspeed instead of trim airspeed
Fixes these invalid format strings:
- A `%d` for a pointer (replaced it by `%p`)
- A 0x%08x (and a 0x%0x8!) for a pointer (replaced by %p)
- 2 cases of `%d` for a `ssize_t` (replaced it by `%zi`)
- 1 case of a %u for an `int` (replaced by %i)
- 3 cases of %d for a `long` (replaced by %ld)
- 19 cases of `%d`, `%i`, `%u` or `%lu` for a `size_t` (replaced it by `%zu`)
- An unused formatting argument (removed it)
- A missing `%d` (added it)
- A missing `%s` (added it)
- 2 cases of `%llu` for a `uint64_t` (replaced it by `"%" PRIu64`)
- 6 cases of giving a string directly as format string (replaced it by `("%s", string)`)
- 2 cases of %*-s, which should probably have been %-*s.
(Looks like NuttX accepts (the invalid) %*-s, but other platforms don't.)
- A %04x for a `uint32_t` (replaced by "%04" PRIx32)
Previously the acceptance radius was 0, so the FlightTaskAutoLine was
randomly changing yaw and sometimes going into a random direction.
There is still something else wrong in there, but avoids the reposition
problem.
Timothy Scott