Mount: fix serial port used for 2nd serial driver #27129
Merged
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
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.
This PR fixes a bug in our three serial mount drivers which currently always try to use the first serial port defined for use with gimbals (e.g. SERIALx_PROTOCOL = 8/Gimbal). The bug appears when the user tries to set up two serial mounts.
The fix uses a similar pattern to our rangefinder drivers in that we track the serial driver instance and pass that into the constructor. This serial instance (instead of the regular instance) is used when searching for the serial port.
This has been lightly tested on CubeRed connectded to a Siyi A8 (over ethernet) and ViewPro A10 (over serial). Below is a picture of the new QGC 4.4 that includes support for controlling multiple gimbals. Using the changes in this PR I was able to control both gimbals independently.
It will likely be difficult to get testing done for the SToRM32.
This resolves issue #27090
FYI @timtuxworth, I'm happy to build you a binary if you'd also like to test. Alternatively it may be merged to master/latest soon.