-
Notifications
You must be signed in to change notification settings - Fork 17k
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
AP_RangeFinder: benewake reports at least 12m or 23m when out-of-range #9778
Conversation
value logged and shown to the user will be at least 12m for TFmini or 22m for TF02 which ensure the user won't see the range drop even if they have configured a very short useable distance
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.
LGTM, although I don't really understand how the last commit is a fix, it seems a NFC change to me. The old code would keep adding and then discard upper bits, the new one will overflow (and so immediately discard the upper bits instead of doing it later).
@OXINARF, I think the key change is actually the "(uint8_t)linebuf[BENEWAKE_FRAME_LENGTH-1]" part. So it was the conversion of the single byte from the buffer that was being converted into an 16bit integer that was not equal to the left. While testing I would see the left side would see things like the left would be 0xF0 and the right would maybe be 0xFFF0 (or something like that). Anyway, thanks very much for the review, this will go out for beta testing today! |
@rmackay9 You are correct, issue is the buffer being of chars instead of uint8_t as it should, I missed that. Reading from the UART to a char is actually wrong as it returns an uint16_t and we should check it isn't -1. |
This PR has two minor improvements:
Here is a screen shot of the RFND message during a bench test with the Benewake TFmini lidar
![benewake-fix3-test](https://user-images.githubusercontent.com/1498098/48459537-dd4f9800-e80d-11e8-9024-8136f1111db6.png)