ardupilot
ardupilot copied to clipboard
Ainstein LR-D1 driver - RangeFinder
Added support for the Ainstein LR-D1 altimeter using @peterbarker original PR as baseline.
- This PR supports the newest FW version 18.x, which rearranged data words 5&6
- Updated get_signal_quality_pct, was unable to compile using the previous implementation.
- Added additional SNR checking for 'invalid altitude readings' according to the datasheet.
- Corrected malfunction codes and added reporting for 'Stop use and check' alert codes.
- This has only been tested on bench top, still awaiting flight testing.
Will be flight testing in the next few days.
I threw this together but haven't run it yet. Let me know what you think https://github.com/magicrub/ardupilot/commit/3d5e4ff01d6cf1a8a6466c63436f8128b25e736d
Thanks for the feedback, looked at your PR and I am going to use your suggestions. Code is much easier to read. Will do ground tests and check in.
still have a few lingering changes (like whitespace stuff) but the commits need to get squashed and the commit text needs to confirm to our standards. Basically, one commit per library
still have a few lingering changes (like whitespace stuff) but the commits need to get squashed and the commit text needs to confirm to our standards. Basically, one commit per library
Will do, planning on flying this build in the next week or 2. Will update the PR with results.
Looks like the failing tests are due to a 503 error on the CI service.
@jkronk That ESP 505 error shouldn't block this PR because it's likely blocking all PRs. We'll get that looked at ASAP.
Meanwhile, still need to fix the commits. Since we have multiple releases on multiple vehicle platforms, we have found that splitting up the commits where each commit only contains changes to a single AP_ library. Makes it much easier to handle for the release managers who cherry-pick things around and backporting and such in the future.
Details here: https://ardupilot.org/dev/docs/submitting-patches-back-to-master.html
Thanks @magicrub
Am flight testing this Friday and will post results then squash my commits
@magicrub @rishabsingh3003 I did notice today the max value cm is an int16 which caps the max value at 32767, this rangefinder technically has a max value of 65535. I was going to override the max_distance_cm() function, but am starting to think it should be changed to a uint16 at the base class level. What are your thoughts on this one?
Is FFFF an error state or is it a valid distance?
Is FFFF an error state or is it a valid distance?
thats the maximum reading from the altimeter saying its out of range, 500m is what they say is 'reliable max', but correct readings can occur up to 65535
@jkronk well that is definitely a discussion for a PR after this one merges. I see what you mean, int16_t for min_cm and max_cm params. That's unfortunate., However, since valid-ish ranges go all the way up to 65535 then setting the params to 0 is the right thing to do.
How did your testing go? Ready to merge this thing? Just need to clean up the commits and remove the unnecessary whitespace change(s). Let me know if you'd like some help with that.
I've rebased, re-juggled the commits and addressed some outstanding feedback. I am told that @jkronk did a flight test with this so lets get this in before it bit rots too much