UAVCAN: fix and improve device_id logic #26135
Conversation
|
Nice, I like doing this properly! However, note that some of the bridges that haven't been modified still leave the bus id as 0, for example rangefinder. Up until now, the "convention" has been to just leave bus id as 0 for everything DroneCAN. If we change that, we should be careful to update it everywhere. There is also some discussion if we actually want to separate DroneCAN buses, or treat them as as one large network. (Are two devices with the same DroneCAN ID on two different buses considered the "same" device, or two different ones?) I did something similar in an old draft, but haven't followed it up properly: |
6d0c478 to
46a8dd8
Compare
067d165 to
6fc57a7
Compare
|
@Claudio-Chies looks like there are some merge conflicts. Also try to avoid force pushing after review has started (if possible), it makes it difficult for reviewers to see what has changed between commits. |
dakejahl
left a comment
There was a problem hiding this comment.
Looking good! Stoked about this, thank you!
6fc57a7 to
0ce1bbf
Compare
Fixes device ID handling in UAVCAN bridges.
Solution
Refactor device ID logic across multiple UAVCAN sensor bridges to use a unified method for generating device IDs.
Changelog Entry
Bugfix: Improved device ID logic for UAVCAN sensors.
Test coverage
-[ ] open, didnt have the time yet.