-
Notifications
You must be signed in to change notification settings - Fork 13.5k
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
UAVCAN SensorBridge Improvements #14345
Conversation
5ec0009
to
786e500
Compare
This compliments my PR for UAVCAN battery support. #14198 |
@JacobCrabill Please upload a log 👍 |
0cd9120
to
dcb2ea7
Compare
Have a log -- will upload once FlightReview is back online Here's some console screenshots from testing: Note that the Zubax is crap and does not get a fix (this is an unrelated issue). However, both GPSs show up via UAVCAN and get published. The above shows that the two external UAVCAN compasses are being published as expected. Note that since the UAVCAN data is sent in units of Gauss using floats, the sensor_mag x/y/z_raw data, once cast to integer type, is essentially always rounded to '0'. |
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.
This looks great, seems like a huge improvement!
ef7a0aa
to
f0578cd
Compare
@dakejahl I've made all of your suggested changes, and I've also rebased (again!) on top of current master. |
4a82cda
to
ca30bd8
Compare
Not sure why this was failing, I restarted CI. It was failing on Otherwise good to merge @dagar |
@dakejahl pushed another commit to restart the CI checks; all good but one. |
Looks like a SITL test for safe landing is failing |
@JacobCrabill It has very likely nothing to do with your changes but the test respectively the simulation running it is probably flaky depending on server resources. The same test passed with my changes and the latest master changes. I tried to just rerun it but it misses a preliminary requirement. We should just rebase on master and push again to see if that was the problem. |
Like expected all tests pass cleanly after pushing a rebased on master version (just to make it a new one): #14424 |
218f01e
to
96ced63
Compare
Thanks @MaEtUgR |
96ced63
to
76f63ed
Compare
Checks passed just before this last rebase, so should be all set once they complete again. Flight Review is also back up, so here's the log from testing yesterday: |
UavcanGnssBridge did not support more than 1 GNSS callback/publisher. This has now been fixed; it works the same as the baro, mag, and flow sensor bridges. The EKF2 still doesn't support more than 2 GPS publishers, however.
Can now see proper UAVCAN bus and unique device ID for barometer instances; optical flow will also have the UAVCAN node ID assigned as sensor ID.
Supposedly multiple sensor callbacks were supported; in reality, this was not the case, as the mag SensorBridge in particular can only calibrate one compass, leading to a race condition on which compass appears first on the bus to get published and calibrated (with no warning to the user that the 'wrong' compass is being used). For sensors with existing generic driver classes (baro and mag) the sensor bridges use these classes for the driver registration, and uORB publication, and calibration interface (ioctl) handling.
Use absolute-zero constant instead of 273.15f Co-Authored-By: Daniel Agar <daniel@agar.ca>
Also add new 'generic' device types for UAVCAN sensors Other misc. cleanup and style changes.
76f63ed
to
31e9f81
Compare
Maybe @bkueng could take a look? |
Can we merge this? |
Looks good to me. Ideas to think about for the next round.
|
Describe problem solved by this pull request
This PR should allow multiple sensors of each supported UavcanSensorBridge type (GNSS, mag, baro, etc.) to be published just like "normal" sensor drivers do. One particularly useful change is that you can now calibrate multiple UAVCAN-connected compasses along with your internal compass(es).
Describe your solution
Describe possible alternatives
Specifically for the compass bridge, the alternative would be to re-implement all of what PX4Magnetometer is already doing. Let's not re-invent the wheel here.
Test data / coverage
This has all been tested on a private fork; when I get a chance I'll test this specific PR and upload logs.
Additional context
I'll also be submitting a second PR soon that allows us to make use of >2 GNSS units connected via CAN (changes to EKF2 to support arbitrary numbers of GPS). My testing to date of this PR's features actually includes those changes as well.