@MerkaTony That’s OK , I will proceed to this test this week and keep you informed here
I did some recent tst and i got up to 8m on outdoors, i need to do some more range testing as soon as i have some spare time.
@nicodh Hello Nicolas,
In my tests i was able to get up to 7,3m, the whole problem occurs when the sensor goes beyond its limit, in which case i get to see from telemetry 1m on the Radar screen and instantly i get no forward movement. I remind that all this i get to see on Loiter mode.
i did not had that issue, at least in my tests. I will search on the logs and try to look for these errors.
I’ll keep you posted
@nicodh Have you the sensor facing forward? if yes. Would you mind send me your parameters to compare with mine?
Tested more settings and issue persisted. Hopefully tomorrow i will have a new FTDI and test the sensor standalone with the Benewake software and see what “values” does it come up with when you point it out of range.
Look here , I can override the problem with Arduino How to make the TFMINI rangefinder talk I2C
Thank you for your tests and reply. I will get a nano on my hands and try you I2C mod and workaround.
So as it seems the TF Mini gives a minimum value when its over its limit!
Would be nice if Benewake would also fix this firmware side to give maximum distance when limit is exceeded so that it does not always have to be through an arduino.
Once again thank you for looking into this!
this morning i have gotten an email from @Siya not tested yet, but i will bench test it later today and share my findings as also make a small video and post it online. Here is the Original e-mail from Siya and since i am new here, i am into taking informations and suggestions on where this might be posted to help other people also (in case it works).
Our engineer find a way to meet your requirement to fix distance greater than maximum range to be 12m without upgrade TFmini firmware, could you pls try below methods and let me know whether it well works ?
Pls check below steps and the attached two pictures FYI:
1, Use USB to TTI UART converter to connect TFmini with PC,
2, Open TFmini windows display program or Serial Assistant software,
3, Send command 42 57 02 00 00 00 00 20,
4, After set up, then you could use the TFmini with 12m range data for distance greater than max range.
Any questions, pls tell.
Thanks & best regards.
Hi, Antonios. Thank you for helping publish here. I attach the two pictures here for reference too.
Pls share your questions if there are any.
If it works, pls share your test here too. Thanks a lot.
After Banch testing both with the Tf GUI and MP, after following the steps of the email from benewake, the results are as follows. I remind that my test TF unit is connected serial on my 2.1PX
On the the MP Radar screen i now get an 11.2m value when i am point the unit in the sky and correct distance values on objects that i had around me for 7m(i did not test in outdoor anything more than that).
I run a series of tests where i would point the sensor on an object and then direct to the sky and the value would change instantly to 11.2m
Since wind conditions and the fact we are expecting rain at any moment, does not allow me to fly and test with actual objects during flight if the sensor will work as expected, i am unable to give additional information, but so far now it seems to respond as it should.
I would like to thank everyone in this post for their responses and Siya from Benewake for there action and hope that this thread my assist other people in the near future.
As soon as flight results come back, i will keep everyone updated.
Hi, this is a real life test.
I think there is a small issue with measurement, the obstacle was a polycarbonate wall, maybe that was a problem for the laser.
TFmini has a IP65 protection version ready soon, anyone that interested in IP65 weatherproof application for this LiDAR, pls check more from Benewake. Contact bw (at) benewake (dot) com for more details.
TFmini now upgraded to new version with IP65 protection. More details below:
"In order to meet the user’s requirement in harsh conditions, we newly added IP65 level waterproof shell to TFmini!
In addition, the switching value function is also added. First, let’s take a look at the changes in appearance.
Left one is the update, is it cool? : )
Those who don’t know TFmini before can get familiar with product through the following introduction.
TFmini Product Introduction
TFmini is a milestone for Benewake to promote the process of low cost LiDAR.
With its unique optical, structural, and electronic designs, the product possesses 3 major advantages: low cost, tiny volume and low power consumption. The built-in algorithm adapted to indoor and outdoor environments can guarantee an excellent ranging performance at a low cost and in a tiny volume, which highly expands the application fields and scenarios of LiDAR and lays a solid foundation for future “eyes” in the smart era.
For more information, please visit our website at http://www.benewake.com/tfmini.html
The highlights of TFmini updating
In order to meet TFmini’s requirement in some harsh environments, we have launched protective accessory that allow the TFmini to meet IP65 protection level, while only increasing a little volume.
We update the firmware so that TFmini can output switching value. Current functions are:
① The standard UART communication can be switched to the I/O push-pull output via a serial command, and it can also be switched back through the command to achieve one-touch switching.
② The distance threshold value of switching can be changed via the serial command to increase the flexibility of uses;
③ Default output states: if there are obstacles (range value within the certain distance), TFmini output high level of 3.3V; if no obstacle or out of range (ranging distance outside the certain distance), TFmini output low level of 0V. The the output level can be changed according to requirements.
Coming soon: Wide power supply voltage of 5-28V; upgrade type TFmini which meets IP65 protection level without customized protective shell; output switching value signal without firmware update requirement and switching value output high level up to 24V. "
Hi, i need a sanity check
I have finished hardware build, drone is up, 2 GPS and TFMini unit. All works fine, lidar provides data as needed.
Now, I believe in order for it to work one needs to activate EK3_ALT_SOURCE parameter?
Its definition states as below:
This parameter controls the primary height sensor used by the EKF. If the selected option cannot be used, it will default to Baro as the primary height source. Setting 0 will use the baro altitude at all times. Setting 1 uses the range finder and is only available in combination with optical flow navigation (EK3_GPS_TYPE = 3). Setting 2 uses GPS. Setting 3 uses the range beacon data. NOTE - the EK3_RNG_USE_HGT parameter can be used to switch to range-finder when close to the ground.
So, if you set EK3_GPS_TYPE =3 - that in fact turns off all GPS support. I do not want that. I want this unit to use lidar altitude when it is within provided range - indoors or outdoors. when out - use GPS or baro, as usual.
The WIKI page simply states like it is supposed to work ‘as is’ -
"Downward facing Lidar are used in flight modes which have height control, such as Altitude Hold, Loiter and PosHold Mode. The data from the sensor will be used until you exceed RNGFND_MAX_CM, after that it switches to the barometer."
So, that last statement sounds like complete common sense - only i have a feel after all tests done today - it is a lie and nothing uses that lidar value with the defaule value of EK3_ALT_SOURCE=0.
So, to simplify this BS - is it doable to use object avoidance and lidar landing/loiter together with GPS active? IF yes, how exactly it should be set and what parameters should be used?
If you want to use rangefinder both indoor and outdoor you need to add opticalflow in order to run loiter in non gps.
This way , you can set the range finder as the primary height sensor (until maximum range and then the Baro or Gps if present are used).
Beware of the fact that the TFMINI works indoor up to 12 Meter but is limited to outdoor at approx 6 Meters so you should be carefull about the settings.
I have not experiment with switching from GPS to OpticalFlow, but I know that it can be done. The problem is when you switch back from OpticalFlow to GPS, there will be a switch from local to global localisation and this can cause all sorts of weird situation going from uncontroled movement to try to correct from localisation error to total loss of EKF … generally it is switching to land
I see, it is making perfect sense but not what wiki gives a perception of, with a statement that alt hold uses rangefinder. I will try to search more, not quite sure how to do this switch from radio controls, from optical to gps flow either. Realistically, we do not need optical flow here, all we need is just a loop to set altitude using rangefinder as primary, if it exists.
Just did some tests, so, with ekf1/2 combo load in prearm is showing %45-%47, freemem says 44208.
With ekf/1/2/3 combo load in prearm is at %64-%67 and freemem is 11407. So, question of the day is - is %67 load level acceptable or not? Go figure…
The switch from GPS to OpticalFlow is automatic within the EKF, just like with 2 GPS its a ‘‘blending’’ of signal and uses the ‘‘best’’ estimator for navigation and if it fails it rolls back to AHRS and ultimately initiate an Land.
If you require more details , I suggest you open a new issue related to this particular to get other people involved.
May be i should, i still hope to find some details about it.
A switch to the optical flow as i see it is not automatic by the way of what is presumed between the lines of descriptions on the EK2_ALT_SOURCE and EK2_GPS_TYPE parameters.
For the first one it says pretty definitively - “Setting 0 will use the baro altitude at all times”.
And indeed it is what i see as indoors baro goes crazy and hits basement`s ceiling. it does not even look at the lidar. Then they continue: “Setting 1 uses the range finder and is only available in combination with optical flow navigation (EK2_GPS_TYPE = 3).”
That, again, presumes that optical flow navigation is not dynamic. I will try next to set EKF2 into EK2_ALT_SOURCE=1 and EK2_GPS_TYPE = 3 and setting EK3_ALT_SOURCE=0 and EK3_GPS_TYPE = 0 but not sure it was supposed to be like that.
Next complication is the AHRS_EKF_TYPE parameter that has to point to the exact EKF model and i do not see any confirmation anywhere that it may ‘switch’ between EKFs or care if one EKF is on lidar for alt and other is on baro.
Donno, all this is as clear as mud and i have no time at all to open up code and read all this stuff that is in there to decipher what is it expected to happen in what undocumented combination of parameters… It is too bad wiki is not updated to actually say HOW to use all those features they listed in there. it simply presumes it is expected to work, and may be it is indeed true, i just cannot figure it out, yet.
I saw some threads asking about same thing and there were responses of the RTFM type pointing to other threads that have 0 usable information. Very odd.
Can you give me a picture of wiring benewake tf mini to pixhawk2 cube ? To my email and all the parameter list
Bayu from Indonesia