Send continuous zero setpoints until landing in ramp examples #529
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In ramp examples where motors are gradually ramped, the supervisor assumes the drone is flying and requires continuous updated setpoints. Previously, a single zero setpoint was sent before sleeping, which leads to supervisor intervention due to missing regular setpoints. Now, zero setpoints are continuously sent for 3 seconds, and the drone is considered landed, preventing locking. Currently, this does not directly check with the supervisor if the drone has landed. Investigating a way to do this revealed that it is not straightforward. In the client, we check the supervisor states through a bitfield check, but there is no direct and easy way to access this information from the library. I will open a new issue to propose adding supervisor state reading functionality to the library, making it easier to access this information directly.
Re-added a slightly modified comment explaining that sleeping before closing the link ensures the last packet is sent, as the message queue is not flushed before closing. While it’s somewhat arbitrary that this information is only found in this example, it’s still valuable to have it documented somewhere. In practice, we don’t care as much about this delay anymore since the new method’s delay is more focused on the setpoint sending loop rather than guaranteeing message delivery, but the comment is still worth keeping.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In ramp examples where motors are gradually ramped, the supervisor assumes the drone is flying and requires continuous updated setpoints. Previously, a single zero setpoint was sent before sleeping, which leads to supervisor intervention due to missing regular setpoints. Now, zero setpoints are continuously sent for 3 seconds (after which the drone can be safely assumed to be landed), preventing locking.
Currently, this does not directly check with the supervisor if the drone has landed. Investigating a way to do this revealed that it is not straightforward. In the client, we check the supervisor states through a bitfield check, but there is no direct and easy way to access this information from the library. I will open a new issue to propose adding supervisor state reading functionality to the library, making it easier to access this information directly.
Fixes https://github.com/orgs/bitcraze/discussions/1852