TF-mini Lidar sensor does not work properly on pixhawk

SpaceGCT · November 6, 2018, 5:01am

TF-mini Lidar sensor does not work properly on pixhawk (Copter 3.6)

But it works well on Arduino.

Should I replace the TF-mini Lidar sensor?

rmackay9 · November 6, 2018, 5:07am

Hi Peter,

In what way is it not working properly?

If it’s reporting 655m sometimes then we have a fix for that coming in Copter-3.6.1 which will start beta testing in a few hours. If it’s something else then we may need to look into the driver further.

SpaceGCT · November 6, 2018, 5:25am

Thanks, rmackay9
I’ll waiting for CP 3.6.1

Sincerely

rerlitz · November 12, 2018, 9:07pm

Hi there, even with the 3.6.1 release i still have problems with the TFMINI lidar.

Configuration done as stated in wiki:
serial4_protocol=9
serial4_baud= 115
rngfnd_type = 20
rngfnd_min_cm= 30
rngfnd_max_cm= 600
rngfnd_gndclear=5

With this config and with the TFMINI straight out of the box the lidar works “properly” until 1.26m (no longer jumps to 654 after this distance) and stays with that value in sonarrange.

Then i connected the tfmini to the pc, entered the configuration and set as default de PIX mode. With this the tfmini no longer works with the pixhawk (sonarrange stays with a value of 0 all the time).

Finally with the tfmini still configured in PIX mode i changed the pixhawk config with rngfnd_type=8 (LightWareSerial) and finally works properly, but this solution triggers a special kind of ocd within me haha.

Am i doing something wrong? Or choosing the rngfnd_type=8 is not recommended in any way for using the tfmini at this time? Any comment would be appreciated.

rmackay9 · November 13, 2018, 12:27am

@rerlitz,

Thanks for the report.

For what it’s worth, my guess is that the lidar is not setting the 7th byte properly to specify that short and long distance mode are available.

I’ve been using my own TFmini and it seems to be working properly so I’m having trouble reproducing the issue you’re seeing.

Your test was done with a pixhawk family of flight controllers or something else?

rerlitz · November 13, 2018, 1:53am

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

rmackay9 · November 14, 2018, 5:04am

@rerlitz,

Could you try moving the lidar to Telem1? It may be that Serial4 cannot provide enough power for the lidar.

@ppoirier,

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).

rmackay9 · November 14, 2018, 6:39am

Ok, so I’ve found a somewhat major bug in the Benewake driver. I’ve created a PR to resolve this and two other non-critical issues and we once it passes peer review we will release Copter-3.6.2-rc1 for beta testing.

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.

ppoirier · November 14, 2018, 8:02am

@rmackay9 I replied on other thread, patch looks ok

rerlitz · November 14, 2018, 10:09pm

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

rmackay9 · November 15, 2018, 5:26am

@rerlitz

If you have time, could you give it another try with 3.6.2-rc2? I hope/expect that this released candidate will resolve the problem.

SpaceGCT · November 15, 2018, 6:59am

Hi Randy

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

Serial 4/5 vloatege 5.2V (tested)

rmackay9 · November 15, 2018, 10:10am

@SpaceGCT, Any chance you can provide a log from 3.6.2-rc2? It won’t show the strings being sent from the lidar but it will show us some other stuff.

SpaceGCT · November 15, 2018, 11:59am

Ok, I’ll send you that logs.

Sincerely

2018년 11월 15일 (목) 오후 7:20에 rmackay9 noreply@ardupilot.org님이 작성:

ppoirier · November 15, 2018, 12:24pm

@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

I can send the log but this images explain it , I think

MartyMcFly · November 15, 2018, 3:04pm

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

rmackay9 · November 19, 2018, 1:38am

@ppoirier,

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.

rmackay9 · November 19, 2018, 4:29am

Patrick,

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.

SpaceGCT · November 19, 2018, 9:12am

Hi Randy

I’ve just tested it that TF-mini Lidar sensor on pixhawk with 3.6.2rc3 beta

It was more reliable

but, It was not accurate within 1m

here is the log

2018년 11월 19일 (월) 오후 1:39, rmackay9 noreply@ardupilot.org님이 작성:

55 1980-01-01 오전 9-00-00.bin.log (1.71 MB)

55 1980-01-01 오전 9-00-00.bin (728 KB)

rmackay9 · November 19, 2018, 9:50am

@SpaceGCT,

Thanks for testing!

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?