I want to use the BENEWAKE TFMINI plus as an altitude sensor for indoor flights.
Right now I have the drone on my workbench so I am not sure if this will effect my problem.
I set up the rangefinder parameters and i can see the correctly measured distance.
However, the altitude in ALTHOLD mode does not refer to this reading ( picture attached)
Basically the questions comes down to this:
a) The Altitude in the HUD does not equal the altitude the controller uses for its calculation
b) For some reason the controller refuses to use the Lidar Reading for the altitude.
Besides the ones specific to the TFmini i set the following parameter:
I don’t have a lot of experience with indoor flight but it looks like the EKF is unhappy for some reason. Maybe try clicking on the EKF label to see why. I suspect if it gets very unhappy with the rangefinder readings it may stop using them.
Attached you will find a picture of the unhappy EKF. The rise of “position (vert)” is induced by shaking my lidar and this is the highest spike that i could create. When the drone is just standing on the bench and the lidar is just aiming on a surface there is hardly any rise.
I can definitely see that position (vert) depends on the movement of the Lidar.
I think that the EKF is unhappy as I am not using GPS and I am not offering a different position system.
I would have questions regarding this warning as I might be misunderstanding the documentation:
If I would not set those parameters and leave them on default, would my rangefinder actually do anything?
I really want to use this drone only indoors in a lab with a bright and very flat ground surface. The barometer however is absolutely useless as a big AC and ceiling fans create a very mixed atmosphere.
Which parameters would have to be set for this usecase? The purpose of the lidar is to create a stable ALTHOLD for trimming and tuning and to make sure that the drone does not rise for the ceiling (8m height)
Great! I will set the parameter EK2_ALT_SOURCE = 1 and try out how it works.
Yesterday did try the drone outside with the recommended settings for terrain following
over a flat surface but added a small table in the flightzone to verify the usage of the rangefinder and it worked fine.
I will try out both settings inside now and give an update.
Thanks for your help!
PS: Should EK2_RNG_USE_HGT be set to -1 or 70? if EK2_ALT_SOURCE is set to 1?
Please note that the detection distance will be shorter in a bright place even indoors. In that case, you need to adjust RNGFND1_MAX_CM and EK2_RNG_USE_HGT. In particular, it is a case of flying near the ceiling 7-8m.
thanks for the input!
I am using the Benewake TFmini plus. So, theoretically the max reading is 10m but my goal is it to keep the drone always below 2m. I tested the reading and I had good readings up until more than 8m.
I will do a testflight soon now and I will leave a note here, how it worked out!
@rmackay9 I am trying to understand the use of EK2_RNG_USE_HGT looking at source but it seems to me that it is never used. The condition in the following if is never false and so the code in the else case is never executed, that means EK2_RNG_USE_HGT (frontend->_useRngSwHgt) is never used. Correct me if I am wrong.
I certainly agree that there is some dead code there introduced by a PR I added a few months back. I’m pretty sure though that the EKF will use the lidar for it’s main altitude estimate. What it won’t do though is switch between baro and lidar when it cross above/below the EK2_RNG_USE_HGT threshold.
In this way the value of EK2_RNG_USE_HGT is not used, it is only tested to be > 0.
Another question: in which condition happens the switch between baro and lidar? When alt becomes > RNGFND_MAX_CM? I don’t find it in the code.
I thought the EKF would switch back to use the barometer (instead of Lidar) if the lidar range becomes longer than >EK2_RNG_USE_HGT or >RNGFNDx_MAX_CM (whichever comes first) but you may be right that this logic is broken. It would be worth testing (a SITL test might be easiest).
For other reading this thread, I’d like to clarify once again that we are discussing a very special case of indoor flight in a room with a flat floor and an air conditioner that upsets the barometer. For terrain following the EKF parameters should not be modified. Terrain following setup advice is here for non-autonomous modes and here for autonomous mode.
I can give a first feedback now:
The drone could hover stabily indoors however there were problems with the reflectivity of the ground.
I took off from the ground and reached around 3ft altitude. The drone was somehow stable but eventually started to raise. I had limited the maximal vertical velocity in altitude mode to 0.5m so the raise was very slow. I landed the drone.
As I suspected the reading of the Lidar to be noisy over the reflective ground I put wooden pannels on the ground and took off from there. I hovered a couple of seconds over the wood and flew over the ground. The altitude remained stable and I did not see a raise. I returned to the wooden pannels and hovered for a couple of seconds and landed.
In the log I can see that the Lidar reading is extremely noisy over the reflective ground but useful over the wood.
However, the good thing about it is that the drone did not go crazy even when the reading was useless. On the bad side, we can see small spikes in the vibration logs during the over above the reflective ground. Attached you will find the log, in case you are interested!
The wiki page linked above (here it is again) is for the EKF1 which we don’t use anymore. Perhaps we should update the page but for now I recommend users look at this EKF wiki page which I know is maintained although it has much less information on it.
By the way, my PR removed the ability to use the rangefinder at low altitudes and the barometer at higher altitudes. This wasn’t completely intentional (at the time I didn’t know the EKF2 even had this feature) but the change was the result of countless support calls from users who had set one of the two parameters (EK2_ALT_SOURCE and/or EK2_RNG_USE_HGT) and had horrible experiences often resulting in crashes. I don’t remember ever seeing a positive report regarding these parameters. Perhaps there are more issues in the EKF in this area, I’m not sure… but disabling the rangefinder + baro mixing has definitely reduced the support calls. I guess my point is I’m not willing to re-enable this behaviour unless it’s proven to be reliable in a wide variety of situations (baro or rangefinder failures, uneven surfaces under the vehicle, rapid climbs and descents, flights right at the threshold of the switch, etc).
Thanks for the feedback on testing and good to hear that it’s basically working.
One thing that seems odd is the EKF appears to be consuming the rangefinder altitude even when it’s clearly bad. The EKF’s altitude is in red, the sonar’s range is in green. The EKF should really only be consuming the altitude when the rangefinder status is “Good” (4).
I took the parameter for rangefinder in SITL from this page, anyway as you said differ only in scaling. I did another test with the params you suggest but the result is the same.
It seems to me that the problems we see on my second test above (with plot and dataflash log) has the same root of the problem on @Frankendrone test: the EKF continue to use rangefinder altitude even when status is not 4 (Good), in my case it becomes 3 (OutOfRangeHigh) over 20m (RNGFND_MAX_CM 2000) and then we see all the weird things.
Does it still keep climbing? I know I had the same the same recently during indoorflight, ended up by setting the Wind_PSCALE parameter to 0 or some other Wind parameter.
I only knows it calculated in wind during flight, so it keeps ascending. Turned that off and it was gone. This happened to me in V3.6…