Hi there, i was playing around a little more with the TFmini and stumbled with an older post that stated that the lidar had to be configured to standard data ouput and milimeters in distance units. With this and rngfnd_type=20 (for tfmini) the values in sonarrange reflected changes in distances measured up to 7m kinda, but the values reflected in sonarrange vs the measured distance had nothing to do one with another.
So far the only way i could make the tfmini work properly was setting it to PIX data output and distance in cm with rngfnd_type=8. Congruent data between sonarrange values, measured distances and datasheet specs.
The testing was made with pixhawk 1 family clone hardware, specifically a hkpilot32, running chibios apm:copter 3.6.1
Do you have any idea what the update rate is for the TFmini? I have been testing some changes and I’m seeing the Benewake TFmini is not providing data at a very high rate (I think).
This commit is the critical one and the issue was that we were not casting the checksum byte received from the sensor to a uint8. This meant that it was being “promoted” to a uint16 and so if the top bit was set we would end up with different numbers. The final result being that we could lose a lot of messages from the sensor.
Hi, it seems you already found the bug, anyways the testing with serial1 were basically the same being:
*tfmini (standard data + cm)
*rngfnd_type=20
-Sonarrange works until 1.26- 1.27m and no longer measures bigger distances, also after 1.26 bad lidar health is displayed.
*rngfnd_Type=8
-wont work at all
*tfmini (Pix mode + cm)
*rngfnd_type=20
-wont work at all, sonarrange=0 and bad lidar health
*rngfnd_type=8
-works perfectly
*tfmini (pix mode + mm)
*rngfnd_type=20
-wont work at all sonar=0, bad lidar health
*rngfndtype=8
-works perfectly
*tfmini (standard data + mm) rngfnd_type=20
-works partially, bad lidar health is always present but the distance in sonarrange measures distances as intended but with a decimal of error (ie. at measured 0.3m it displays 3m…at 4.12m sonarrange displays 41.2m)
*rngfnd_Type=8
-same results as with type=20
I’ve just tested it that TF-mini Lidar sensor on pixhawk with 3.6.2rc2 beta
TF-mini standard format -> Lidar ok, but still have problems
Chagned the error value: 655m -> 13m
Distance measurements were not reliable
TF-mini pixhawk format -> Lidar error, it doesn’t working
rngfnd_type=20
TF-mini output data format
42 57 02 00 00 00 01 06 Standard format, as show in in Table 6 √
42 57 02 00 00 00 04 06 “Pixhawk” data format /
by TF-mini manual
@rmackay9 , there is still a problem with the driver, seems it is(skipping_ shifting) a bit… I cannot read some distances like in the forties ( from 39 - 50 cm) take a look to the pattern on both proximity & rngfinder signals
just been out flying with the TF mini i have the rangefinder on a switch set type to 8 and pixhawk was ticked in the GUI it flew the best alt yet at 2 mtrs not sure if this helps
Thanks for testing the changes. I’m not sure I’m able to reproduce the issue but I was wondering if you could try testing this binary (built for pixhawk/cube on ChibiOS). This includes a change to avoid further char-to-uint8t conversion issues by holding the buffer in uint8_t which is what @OXINARF has suggested we do. The link to the code is here.
Below is a graph of what I see when I tested 3.6.2-rc2.
and here’s what I see with a similar test with the new version. It does seem more reliable actually and I suspect the issue is this line which was missing a cast to uint8_t when calculating the distance.
I’ve push out -rc3 which includes the fix above. I’m pretty sure this is going to fix the problems you’ve found so if you could give -rc3 a try that’s be great. Txs for all your help in getting to the bottom of this.
Hard to say if that’s a sensor issue or a driver issue though right? Certainly with the number of driver issues we’ve had it would be fair to think it’s a driver software issue… but is there any other reason to think this? For example do alternative drivers (i.e. @ppoirier’s method) or the lightware-serial driver produce better results?
It looks like with firmware version 16x they replaced mode 02, 07 by mode 00, 03, 07.
Sparkfun delivered a Tfmini with 160 firmware recently.
It works fine with an Arduino serial-i2c converter based on https://github.com/opensensinglab/tfmini . From what I have seen in this Arduino-lib they do no distance scaling according to the mode at all. Returns always cm.
In contrary AP_RangeFinder_Benewake.cpp scales distance by factor 0.1 in mode 2.
But mode 2 does not exist with firmware 16x devices anyway.
Thanks for looking into this. So I guess during the test the sonar was much more than the 9cm to 12cm shown in the log? … and presumably we think the issue is that the mode is coming out of the sensor as “2” and is being made 10x smaller than it should be? If true this is a bit of an issue because I’d say this would be a “breaking change” by benewake. In that it’s not backwards compatible.
