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

ArduPlane: make Guided update frequency limit configurable #28526

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

Conversation

timtuxworth
Copy link
Contributor

in Guided mode, the current code throttles updates from externally received messages that updates roll, pitch or throttle. allowing a maximum of one update every 3 seconds for any external message

For Plane Follow, the lua script runs at 10Hz, so this limit prevents it from working properly.

So as not to change existing behavior, I made it a new parameter GUIDED_UPD_LIM - in milliseconds, default to 3000.

@timtuxworth
Copy link
Contributor Author

I found this was required for plane follow to work. Does this make sense @peterbarker @IamPete1 ?

@IamPete1
Copy link
Member

IamPete1 commented Nov 5, 2024

You can update roll/pitch/throttle as fast as you like. I think the issue your having is that you can't swap from roll/pitch/throttle commands to a navigation command quickly because the timeout has to elapse?

@timtuxworth
Copy link
Contributor Author

You can update roll/pitch/throttle as fast as you like. I think the issue your having is that you can't swap from roll/pitch/throttle commands to a navigation command quickly because the timeout has to elapse?

That might be what's happening @IamPete1 - the one that impacts me most is throttle, as in follow I am trying to navigate and also potentially adjust speed every loop. My use case is always level flight.

@IamPete1
Copy link
Member

IamPete1 commented Nov 6, 2024

How about a update to handle_set_attitude_target such that if the bits are not set the time stamps are reset? This has the advantage that you can reset instantly rather than just having to wait for a smaller timeout.

@timtuxworth
Copy link
Contributor Author

How about a update to handle_set_attitude_target such that if the bits are not set the time stamps are reset? This has the advantage that you can reset instantly rather than just having to wait for a smaller timeout.

I'm not using SET_ATTITUDE_TARGET - I'm using GUIDED_CHANGE_SPEED.

@IamPete1
Copy link
Member

IamPete1 commented Nov 7, 2024

I'm not using SET_ATTITUDE_TARGET - I'm using GUIDED_CHANGE_SPEED.

GUIDED_CHANGE_SPEED commands don't use the timeouts your changing here? You must be using SET_ATTITUDE_TARGET somewhere or this change would make no difference?

Maybe you can explain the exact commands your using.

@timtuxworth
Copy link
Contributor Author

I'm not using SET_ATTITUDE_TARGET - I'm using GUIDED_CHANGE_SPEED.

GUIDED_CHANGE_SPEED commands don't use the timeouts your changing here? You must be using SET_ATTITUDE_TARGET somewhere or this change would make no difference?

Maybe you can explain the exact commands your using.

I'm sure I found that this code was being hit by putting a breakpoint there, bit I can't remember the details now, so I'll see if I can duplicate the problem.

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

Successfully merging this pull request may close these issues.

2 participants