Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AP_Follow: change to using position-from-origin internally #27250

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

peterbarker
Copy link
Contributor

@peterbarker peterbarker commented Jun 6, 2024

This work sponsored by Freespace Operations

In preparation for kinematically-consistent target information.

@amilcarlucas
Copy link
Contributor

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

@peterbarker peterbarker force-pushed the pr/follow-offset-from-origin branch from 57860f0 to edf026e Compare June 20, 2024 01:03
@lthall lthall requested review from rmackay9 and lthall June 20, 2024 01:05
@peterbarker peterbarker force-pushed the pr/follow-offset-from-origin branch from edf026e to e7de2cc Compare July 1, 2024 06:50
@peterbarker
Copy link
Contributor Author

Fixed problems caused by rebase on top of function rename in master

@peterbarker peterbarker force-pushed the pr/follow-offset-from-origin branch from e7de2cc to 7e5a829 Compare August 5, 2024 01:45
@rmackay9
Copy link
Contributor

rmackay9 commented Aug 5, 2024

I think we just need to be careful that we cover all situation:

  1. handle AHRS failing to provide a position
  2. handle situations where the lead vehicle is using different altitude frames (absolute, relative and terrain following)

@timtuxworth
Copy link
Contributor

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?

@timtuxworth
Copy link
Contributor

In preparation for kinematically-consistent target information.

What does that mean?

@lthall
Copy link
Contributor

lthall commented Aug 5, 2024

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.

@timtuxworth
Copy link
Contributor

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()

@peterbarker peterbarker force-pushed the pr/follow-offset-from-origin branch from 7e5a829 to c4c6c20 Compare September 6, 2024 03:27
@peterbarker
Copy link
Contributor Author

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.

@timtuxworth
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants