-
Notifications
You must be signed in to change notification settings - Fork 13.6k
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
Migrate vl53lxx driver class member variable initialization to declarations, formatting, and deprecate IOCTL usage. #11896
Conversation
7075524
to
5124e22
Compare
Do you have time test this on Pixhawk4 I2C A port, I think it's not working. |
5124e22
to
2bfcccc
Compare
Hy @bys1123 , I do have time, but unfortunately I do not have hardware to test with. I have a Sensordots Mappydot+ and functional driver, (https://sensordots.org/mappydot_plus), so I've spent some time combing through the vl53lxx driver and pushed up another commit to this PR with a bit more code cleanup. If you might be willing, try out this PR and make sure to start your driver with |
168892a
to
ea09827
Compare
@mcsauder Thanks very much, but I realized this vl53lxx driver is only for vl53l0x, vl53l1x's registers addresses is very different with this one. Hope maybe you could make a vl53l1x driver some time. |
Thanks! |
213314a
to
54bda63
Compare
@bys1123 , I've made an attempt to create functionality for the vl531x sensor in the latest commit to this PR. I appreciate any feedback from testing you can offer. You will need to alter lines 71/72 to build for either the vl530x or vl531x. If there is a more elegant solution to this please clue me in! :) |
54bda63
to
1d2f3ce
Compare
@mcsauder
|
@bys1123 , Thanks for your feedback! I obtained/modified the VL53l1X register map from ST's Likewise, I obtained/modified the register map for the VL530X from ST's We have a choice... match the ST api, or be self-consistent within the PX4 code base. I am interested in advice! |
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.
I think there is no need to match the ST api. Look like the whole project only consider self-consistent (personal opinion).
|
||
writeRegister(0x81, 0x00); | ||
writeRegister(0xFF, 0x06); | ||
|
||
readRegister(0x83, val); | ||
writeRegister(0x83, val & ~0x04); | ||
writeRegister(0x83, val & ~0x04); | ||
|
||
writeRegister(0xFF, 0x01); |
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.
There is lot of hard coded registers in the driver, so I think it will not work for VL53L1x.
@DanielePettenuzzo Do you have any idea how to add the vl53l1x's driver is the best? |
1d2f3ce
to
ea09827
Compare
Hi @bys1123 , Sorry that it wasn't an easy hack to get this driver to play nicely. The hard coded values in the current driver do not have aliases in the ST API for that sensor and searching the web it appears that ST is not inclined to distribute a full register map for that device. So, I've reverted this PR back to its' original intent and we can work on opening up a new PR to introduce the vl53l1x driver. Thanks for making a quick attempt with me on the vl53l1x! @DanielePettenuzzo , if you are willing/able to test this PR on hardware at your leisure, I am happy to start fleshing out work on a driver for the vl53l1 using the work in this PR to start from. |
ea09827
to
a6e550d
Compare
@mcsauder Do you think it's better call this driver "vl53l0x" instead of "vl53lxx" ? |
@bys1123 , thanks. Yes, I do. I'd like to propose that change when we submit a vl53l1x driver PR. (I'm making progress on that implementation but am not at a point I can open a PR yet. :} ) |
a6e550d
to
004d32e
Compare
I've tested this driver before you optimize it. I'm not sure are your changes fix that? |
@bys1123 , you are correct, my changes do not fix that yet... I will do some digging and see if I can correct that behavior in this driver. Updates to follow! Thanks! |
ea52d7d
to
fabfff5
Compare
fabfff5
to
a0daf5e
Compare
@@ -891,16 +797,15 @@ VL53LXX::sensorTuning() | |||
writeRegister(0xFF, 0x00); | |||
writeRegister(0x80, 0x00); | |||
|
|||
return OK; | |||
return PX4_OK; |
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.
PX4_OK is not the correct return value when returning bool
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.
Return type modified to int
. Let me know if you'd prefer to see anything different.
Thanks so much for your review!
|
||
return PX4_OK; |
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.
PX4_OK is not the correct return value when returning bool
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 @LorenzMeier , you are absolutely correct. Nice catch! The method return remains the same value, but it was certainly wrong previously.
For the convenience of other readers: from px4_defines.h
:
#define OK 0
#define ERROR -1
To preserve the return value I have changed bool
method return types to int
, this matches convention in this and other driver method return types. If you would prefer otherwise just let me know!
Thanks again for catching this!!
Rebased on current master and bench tested.
a51af15
to
c34fc55
Compare
@mcsauder could you recommend something for the @PX4/testflights to pickup? |
Hi @dagar , thanks. Yes. This is the unit I am using for bench testing: https://www.robotshop.com/en/tof-range-finder-sensor-breakout-board-voltage-regulator-vl53l0x.html If this PR is able to be accepted/rejected I am happy to proceed with the VL53L1X driver work creation I have in queue. The VL53L1X sensor is a better sensor on all accounts, there are two easy choices for that sensor:
I have the sparkfun VL53L1X sensor. I almost have a flight test rig finished with this unit. I will post flight results here when I complete the build. |
c34fc55
to
d27e7bf
Compare
2254503
to
2cf4aad
Compare
@DanielePettenuzzo and @dagar, here is a flight log running this PR: https://review.px4.io/plot_app?log=0937ae19-5987-4970-a273-992e59c13d67 Here are the distance sensor readings from the same log: I would like to finish off this PR before working on the vl53l1x implementation. Would you like to see anything else from this PR? Thanks for your feedback! |
…uniform initialization in vl53lxx.cpp. Format whitespace. Alphabetize/group/order variables and methods. Deprecate IOCTL usage and simplify a few methods. Modify return types to correct errata in sensorTuning(), singleRefCalibration(), and spadCalculations() in vl53lxx.cpp.
2cf4aad
to
d9f4a7a
Compare
The distance sensor data in that log looks terrible. Sensor basically became useless after 0.7m? |
I do agree, however, this flight test was probably worst case; the flight test was over grass in direct overhead (bright summer) sunlight. However, the VL53L1 is a much, much better sensor than the VL53L0X. |
Just double checking that it didn't get any worse. |
Thanks @dagar! |
Describe problem solved by the proposed pull request
This PR migrates vl53lxx class member variable initialization to respective declarations, formats whitespace, and alphabetizes/organizes variable and method declarations in vl53lxx.cpp.
This PR is primarily copy/paste of the variable initialization values and method declarations along with whitespace formatting but also renames/refactors task_main_trampoline() and task_main() to match convention in the other distance sensor drivers.
Describe your preferred solution
Standardizing all of the distance sensor driver variable initialization, method ordering and general style will allow for future inheritance structure work to be performed on the distance sensor driver classes.
Describe possible alternatives
All of the distance sensor driver work could be accomplished in one massive PR, but breaking up work in each driver should minimize risk and reduce review effort.
Additional context
See #9279, #11853, #11857, #1858, #11859, #11891, #11892, #11893, #11894
Please let me know if you have any questions on this PR. Thanks!
-Mark