Servers by jDrones

Benewake TFmini LIDAR works on Ardupilot

Yeah, feel like the Sparkfun offering confuses the matter. This device, part of that product, is a separate serial-to-i2c converter, produced by Benewaake, which would work just fine with any TFMini:

That’s not the same as the circuit in the other image, which appears to show an actual TFMini module that natively supports I2C (which is also what the thread about firmware elsewhere implies).#

My question, basically, is: Is there a separate TFMini module that supports i2c without the “boost” board? If so, where can one get it and other related questions.

1 Like

This is not a Serial to I2c converter, it is a power conditionner + a I2C bus driver… look on previous posts above , I made the same wrong assumption :wink:


Aha. Thanks so much, that makes a lot more sense!

1 Like

Hi, everyone. TFmini I2C version and TFmini UART serial version are two different versions, we could say they are different TFmini. : )


Thanks for the clarification Siya. That being the case, a few questions:
If there, or will there be, an i2c version of the TFMini Plus?
Is SparkFun currently the only place stocking the i2c TFMini?

@Shao Yes, TFmini Plus will have I2C version too, it will be ready after some time. Now Sparkfun have the I2C TFmini, other distributor will have it after some time.

New LiDAR TFmini Plus is developed based on TFmini, higher accuracy, higher frequency 1000Hz, IP65 weatherproof case, and can be found on IR-LOCK store:

1 Like

I have tried this setup exactly as well as rngfnd_type, 20. Is 20 supported on 3.6.6 stable? In either case I only get Bad LiDAR health. I have tried ticking pix mode as well as sending the string of characters using the TFMini Tool. Any Insight?

For those here eager to test, I just submitted the PR to support TFMini Plus on I2C:


Hi @lucasdemarchi, great work!
I have no Plus to test, but I tried to get work the TFMini i2c (no plus) version, but for some reason with no luck.
The Plus version seems having different protocol, unfortunately.

What is the reason here to do two transfer() calls instead of single call?

void AP_RangeFinder_Benewake_TFMiniPlus::timer()
{ …
ret = _dev->transfer(CMD_READ_MEASUREMENT, sizeof(CMD_READ_MEASUREMENT), nullptr, 0);
if (!ret || !_dev->transfer(nullptr, 0, (uint8_t *)&u, sizeof(u))) {

Good evening lucasdemarchi.

This is very interesting. Is this for collision avoidance (multiple TFMini plus) or altitude control?



Yes, with I2C you can use multiple devices for avoidance and altitude range

@Sergey_Zakhodylo TFmini has another protocol and the sensor that supports uart doesn’t support I2C. You need a TFmini Plus for it to work.

2 transfer calls because the sensor is not an usual I2C sensor with a regmap. Maybe it works with transfer only, but it’s not what is documented

@henrik04 can be used for either or both.

I mean your two lines are equivalent to
_dev->transfer(CMD_READ_MEASUREMENT, sizeof(CMD_READ_MEASUREMENT), (uint8_t *)&u, sizeof(u));

Either the single-line version doesn’t work for some reason or I missed something

if you do a combined r/w you will have only one stop at the end of the transaction in the I2C protocol.

we actually have support for “split-transfer”, but that just moves the double transfer to the lower layer (see the HAL implementation for I2CDevice):

    if (_split_transfers && send_len > 0 && recv_len > 0) {
        return transfer(send, send_len, nullptr, 0) &&
            transfer(nullptr, 0, recv, recv_len);

What I may test is if the sensor support the repeated start… It’s not documented as supporting though.

You’re right, just checked TFMini Plus docs. There is a 100ms delay also required between W-stop and R-start.
The i2c protocol between not-plus and plus version is very different. Not-plus instead requires for a restart condition after command sent. Looks like FW for plus and not-plus was developed by different teams))

@lucasdemarchi @ppoirier

So as ppoirier described it in another thread: 3 TFmini at the front, one for above in relation to collision avoidance.

Now the bottom one: Can the same unit be used for precision altitude landing and collision avoidance or not?

In regard to the back of a multi rotor: Are three units at the back needed too?

This would make 8 or 9 units for complete collision avoidance!

Would a LeddarVu at the front one at the back and two TFmini for top and bottom would make sense?

(See attached pdf for LeddarVu)



LeddarVu.pdf (1.47 MB)

@henrik04, you can use whatever configuration you like as long as you provide proper supply and devices adressing. We have only the LeddarTech Leddar One driver for the moment,

Have you looked at my blog ?

I certainly did! Thank you for answering.


@lucasdemarchi what FC you used for testing the Plus driver?

Servers by jDrones