AP_Follow: change to using position-from-origin internally
This work sponsored by Freespace Operations
In preparation for kinematically-consistent target information.
Lokks like a relatively small change:
Binary Name Text [B] Data [B] BSS (B) Total Flash Change [B] (%) Flash Free After PR (B)
--------------- -------------- ----------- ------------- ---------------------------- -------------------------
ardusub 0 (0.0000%) 0 (0.0000%) 0 (0.0000%) 0 (0.0000%) 388464
antennatracker 0 (0.0000%) 0 (0.0000%) 0 (0.0000%) 0 (0.0000%) 637308
ardurover 684 (+0.0418%) 0 (0.0000%) -4 (-0.0015%) 684 (+0.0417%) 326604
arduplane 752 (+0.0422%) 0 (0.0000%) 0 (0.0000%) 752 (+0.0421%) 180200
arducopter-heli 732 (+0.0409%) 0 (0.0000%) 4 (+0.0015%) 732 (+0.0408%) 171880
blimp 0 (0.0000%) 0 (0.0000%) 0 (0.0000%) 0 (0.0000%) 614112
arducopter 716 (+0.0401%) 0 (0.0000%) -4 (-0.0015%) 716 (+0.0400%) 177320
Fixed problems caused by rebase on top of function rename in master
I think we just need to be careful that we cover all situation:
- handle AHRS failing to provide a position
- handle situations where the lead vehicle is using different altitude frames (absolute, relative and terrain following)
There are Lua bindings for some of these functions so they are not "internal". I'm currently using them and expecting them to return lat/lng - is that going to change?
In preparation for kinematically-consistent target information.
What does that mean?
In preparation for kinematically-consistent target information.
What does that mean?
Currently the position jumps each time we get a new update and the interpolation between updates is very basic.
I have been using real-time S-Curves to generate a kinematicly consistent interpolation of the follow me data. I am doing this in pos/vel/accel and heading/heading_rate. This lets you do wonderfully smooth follow-me behaviours. It also acts as a filter for position / velocity noise in your follow-me data.
I'm relying on these methods returning lat/long via the Lua bindings as I use the results to call back in via the new MAVLink DO_REPOSITION interface to point the vehicle at the calculated target location. If these change to returning position relative to origin, will my Lua scripts break?
get_target_location_and_velocity()
get_target_location_and_velocity_ofs()
get_target_dist_and_vel_ned()
I'm relying on these methods returning lat/long via the Lua bindings as I use the results to call back in via the new MAVLink DO_REPOSITION interface to point the vehicle at the calculated target location. If these change to returning position relative to origin, will my Lua scripts break?
Yes, they absolutely would break. Really, really badly.
OTOH, you might have missed the word "internally" in the PR title.
We have no intention of breaking everybody's (eg.) Plane ship-landing scripts by changing the existing "location" bindings, but we will almost certainly add some "position" (offset-from-origin) bindings to LUA at some stage.
I'm relying on these methods returning lat/long via the Lua bindings as I use the results to call back in via the new MAVLink DO_REPOSITION interface to point the vehicle at the calculated target location. If these change to returning position relative to origin, will my Lua scripts break?
Yes, they absolutely would break. Really, really badly.
OTOH, you might have missed the word "internally" in the PR title.
We have no intention of breaking everybody's (eg.) Plane ship-landing scripts by changing the existing "location" bindings, but we will almost certainly add some "position" (offset-from-origin) bindings to LUA at some stage.
Thanks @peterbarker - I'm really looking forward to this feature going in. After talking to @lthall - now I understand what it's doing, I expect kinematic extrapolation to make a significant improvement to the plane follow Lua function too.
Is this ready to take to a dev call?
please check quadplane ship landing lands within a reasonable distance of the ship target
Augmented the ShipLanding test to check the distance after disarm