I have seen some threads but do not see any good solutions. Here is what I am trying to do:
I need to fly indoors in somewhat confined spaces (think bedrooms, kitchens, etc.) on a 3.5" ducted frame. I have Loiter with Optical Flow + Rangefinder working pretty well. I am able to fly around an open space maintaining altitude. However, even with surftrak off, the drone will increase altitude when it flies over an object, say, for example, a kitchen table. This would be problematic if flying through a window. This behavior is quite understandable given that the range finder is the primary altitude source.
Is there a way to somehow prevent that rise in altitude though? My understanding is that using the barometer for altitude in confined spaces introduces variables from ceiling fans, air conditioners, etc. That’s why I switched to the range finder for POSZ. How could I maintain a relatively consistent altitude regardless of objects underneath, without using the barometer? For reference, I am using a MatekH743 Mini V3 and an MTF-01.
POSXY = 0
POSZ = 2
VELXY = 5
VELZ = 0
YAW = 1
I am wondering if it is possible to fly to a spot via Stabilize, then enter Loiter mode. Meanwhile, a Lua script is monitoring this activity and once Loiter is engaged, save the altitude in SCR_USER1 and use it to offset the range finder readings to maintain that altitude? Then, if the pilot changes altitude via throttle, update the SCR_USER1 value?
As for flying without rangefinder as the primary source, it is possible but there will be drift. i have done tremendous testing and found that the altitude will drift about 10-50 cm or more depending on the condition it might not be acceptable in some cases but it is the limitation of using baro as the primary source ( fusing with range finder in EKF)
i believe the best way for rock solid indoor altitude in uneven surfaces is to use some sort of SLAM
you need to also keep the Matek mini away from rotor wash
PosZ need to be 0 for all source 1-3
It means flying indoors using Optical Flow and a Rangefinder for positioning, with SurfTrak disabled (likely referring to surface tracking or terrain following). This setup helps with stable altitude and position hold but may not compensate for drift over time.
There is a parameter that reduces the response speed of the rangefinder to changes in altitude. I don’t remember which one, but it shouldn’t be a problem to find it. This will only help if the altitude difference appears and disappears quickly.
Finding the throttle value needed to maintain altitude in FlowHold or Stabilize mode is not a problem. It can be calculated from the logs, for example. However, the throttle near the surface and further away from it will be different due to the ground effect.
Using a companion computer, it is possible to create a PID system for this situation, dynamically receiving altitude and thrust data, collecting and applying information about various values at different heights above the surface. Something like this can be done if it is worth the effort. The task will not be easy.
@Zeke_De_Zilva I am sorry for the confusion. I am not flying with barometer, because I understand there will be factors affecting altitude. I am flying with range finder.
For clarity on this thread, there is no option for companion computer.
Also, I am not actually looking to adjust throttle because I do not want the drone to change altitude. I want the autopilot to compensate for objects on the floor when it reads data from the range finder in order to prevent rising into the ceiling of a room.
if the ek3-srcx-posz = 2 (rangefinder) and the vehicle is not flying over flat ground the EKF’s altitude estimate will be bad. Every time the vehicle flies over something, the EKF will struggle for a bit to figure out what the correct altitude should be as it tries to make sense of the rangefinder data not matching the IMU.
What’s I’ve found is that the vast majority of users who set EK3_SRCx_POSZ = 2 really want is surface tracking and/or terrain following and those features handle the error within the position controllers not the EKF. Making both the position controller and EKF try to handle the position error leads to conflict.
It is almost never a good idea to set EK3_SRC1_POSZ = 2 (rangefinder). I think it would be best to go back to using the barometer (e.g. EK3_SRC1_POSZ = 1) if at all possible. I hear that some very small vehicle’s barometer can be affected by the prop wash but still, if the ground below the vehicle’s isn’t flat and the baro is affected by prop was then the vehicle doesn’t have a good source for vertical position.
We don’t recommend using FlowHold mode (see warning just below the video on the wiki). It was designed for the skyviper which didn’t have a rangefinder. For vehicles with a rangefinder it’s much better to setup the optical flow as described on the wiki (e.g. EK3_SRC1_VELXY = 5) and use the regular position control modes including loiter.
Would a rangefinder facing up stop it from rising, or at least stop it rising up into something.
I find flow hold very useful for flying indoors, for the simple reason none of the other position hold modes will work without you setting a position first, that means you cannot fly it without mission planner in loiter mode. But i can just take off and park it in the centre of the room without any issue in flow hold. The rangefinder still works in flow hold mode, I can switch between flow hold and alt hold without any issue.
The big problem with FlowHold is that it generates tons of support calls because it doesn’t work on many frames and/or doesn’t work with many optical flow sensors. It’s very frame and sensor specific. I think the issue is that the algorithm is very sensitive to the lag of the sensor
An upward facing rangefinder will stop the vehicle from climbing into something but only if simple object avoidance (aka stopping) is enabled and the vehicle has to be in a mode that controls altitude (e.g. not stabilize or acro mode)
I did find that flow hold could start shaking if you were aggressive with the controls, I only use it for slow repositioning, I think I had to reduce the gains a lot to make it behave and not shake,
I have been using the CXOF, its been surprisingly good on my 10inch xl frame and the 1 hour ultralight. I have a px4 flow but I ended up not using it because the CXOF worked well enough and weighed nothing.
BTW, I think optical flow sensors with a built in IMU will be more reliable on more frames. The reason is that it’s important that AP’s EKF can remove the portion of the flow sensor’s output that is caused by the vehicle’s roll and pitch rotation (so that it is left with only the output that is caused by the vehicle’s lateral movement). If the sensor doesn’t have an IMU then the autopilot’s IMU must be used which might be fine, but if the IMU is on a soft mount while the flow sensor is hard-mounted there can be a difference.
TBH, this is a bit anecdotal and I haven’t done a lot of testing
I did just pick up an Ark Flow and plan to install and retest. I’ll try to collect Loiter and AltHold data with the MTF-01 and then with the Ark and post for those interested.
That’s interesting, I wonder if that is the source of the shaking, aggressive manoeuvres causing frame or mount flex that is then causing the optical flow to get out of sync with the gyro. so when I reduced the flow hold gains it caused it to flex less and therefore reduces the shaking…
MMM, from what you describe is what in AUV is known as follow roof. rather than using floor you follow the roof. AUVs had a secondary sonar for this applications and switch between behaviors in the mission. Very useful to navigate under ice. I had done this in Moose and it is the same that following floor except the inverted direction.