-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Gimbal manager/status - device ids #1988
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much for this. This is fine or alternatively we could make it completely consistent with the other gimbal_device_id field descriptions by making it, "Component ID of gimbal device to address or 1-6 for non-MAVLink gimbal".
@rmackay9 I don't want to make it completely consistent because that other field is a setter command. So the value can be set to zero. In these cases the value is the reported value of the device ID, and as discussed, must not be zero. Hope that makes sense. |
Great. I think we have agreement. Merging. |
* Gimbal manager/status - device ids * Update message_definitions/v1.0/common.xml * Update message_definitions/v1.0/common.xml
* Gimbal manager/status - device ids * Update message_definitions/v1.0/common.xml * Update message_definitions/v1.0/common.xml
* Gimbal manager/status - device ids * Update message_definitions/v1.0/common.xml * Update message_definitions/v1.0/common.xml
This change arises out of #1980 (comment) "should the device id be 0 or 1 indexed"
@julianoes I have taken the text you suggested from GIMBAL_MANAGER_SET_ATTITUDE. However I'm not completely convinced it is correct to use gimbal component IDs.
The id absolutely does have to be indexed from one. However I thought the concept of the id as set in the manager was to abstract component IDs for the gimbal - so we'd always use 1-6 and not have to think about what device IDs were actually mapped to - the manager would sort that out.
Conceptually I find that much easier when working with a gimbal manager. I'm also a bit worried that you might have both mavlink and non-mavlink gimbals and then it isn't necessarily obvious whether you think you're talking to a component id 1 or a device that is mapped to one.
The only reason we couldn't do this is if something other than the gimbal manager needs to directly know the component IDs of the gimbals, and there is no way to infer the mapping from the gimbal manager.
What am I missing? (I could be completely wrong about the intent)