Hi, everyone. TFmini I2C version and TFmini UART serial version are two different versions, we could say they are different TFmini. : )
2 Likes
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:
3 Likes
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))) {
return;
}
Good evening lucasdemarchi.
This is very interesting. Is this for collision avoidance (multiple TFMini plus) or altitude control?
Cheers.
Henri
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
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))
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)
Cheers
Henri
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, Rangefinders (landing page) — Copter documentation.
Have you looked at my blog ?
Much easier to replicate now with the I2C sensors you can connect directly to the FC
Hey!
Wonderful work! Any estimate as to when this will be available in a stable release?