I intend to use a Hereflow on the drone for indoor flights on metal structures. I did the automatic calibration of the Flow_F and got great results so I started to start the tests. (Congratulations to the developers! This feature helped me a lot, since I didn’t get good results calibrating manually).
On the first test flight in FlowHold the drone held the position very well. So I followed with the final tweaks of the Wiki changing the parameters of EK3_SRC…
After changing the parameters, I went to make a new flight in FlowHold and AltHold and I found a problem. The drone is no longer responding to the Throttle to raise altitude, it only responds to take off, but then slowly loses altitude and crashes into the ground.
Notice in this graph below that I keep Throttle at 100% and the drone does not gain altitude.
Don’t worry about the crash messages in the log, I was doing the tests in a grassy area and the drone has a globe around it that doesn’t allow the propellers to touch the ground or another object, so it would just turn up and try to take off again.
I solved the problem by disabling the hereflow rangefinder. To solve the problem I had to compare all the parameters by Excel to identify what was different in the log of when the engines responded to Throttle.
Interestingly, it was not on the first post configuration flight of the rangefinder that the Throttle stopped responding, but after the second flight, that is, the problem did not appear to be in the rangefinder.
I believe the Ardupilot team should invest this problem as it should work perfectly with the enabled rangefinder. I add the @rmackay9 for knowledge.
With Rangefinder off I also get good results flying in Flowhold, the only thing that is now bothering me is the recurring IMU stopped aiding messages.
In this first graph you notice that I keep Throttle at 100% and we have no variation in altitude of the aircraft.
I’ve put the full answer over on this discussion but I think this is known behaviour and it is because AP stops the vehicle from climbing in Loiter or PosHold mode beyond the rangefinder’s limit (RNGFNDx_MAX_CM) because when using optical flow the EKF also needs to know the vehicle’s altitude above the terrain (i.e. rangefinder distance).
We also need to fixup the wiki because this important info is missing. Sorry about that!
Hi @rmackay9 thanks for the answer. This behavior is also seen when we add a rangefinder forward to avoid obstacles. I believe it should only happen with a rangefinder down, correct?
Note that i take off with the drone and keep the throttle at full and the drone does not gain altitude, when I change the flight mode to FlowHold the drone gains a little altitude, but soon descends again.
A curiosity is that the drone does not climb to the maximum altitude of the lidar, but to 1 meter of altitude, that is, not using the parameter RNGFND1_MAX_CM as a reference of altitude limit.
Is the rangefinder meant to be facing down or forward? RNGFND1_ORIENT,0 or should it be 25 ?
You dont appear to have any other rangefinder pointing down.
Part of the problem is the motor outputs are going to much higher than ideal just to get 1m altitude.
Battery voltage sags a bit more than I’d expect too, but not so it’s a big issue.
However Throttle output is only going to approximately 50%, which is a bit odd (to me).
Maybe Randy can pick up on something else that I’m not seeing. I feel that disabling the rangefinder would allow more normal flight (given that the copter seems overweight) indicating that there is still some config issue. The rangefinder distance doesnt match well to any other altitude measurement.
Could you try hovering and some simple manoeuvres in Stabilise mode please with rangefinder disabled, and send that log file? Just to give a good baseline. You might already have a suitable log.
About the problem addressed in this topic, whenever a Lidar is installed with the orientation down or up, the throttle is limited to 50%. When Lidar is disabled, altitude is matched to the applied throttle.
Randy was suspicious that the altitude was being limited due to the range of the lidar, but in this last test I did, I identified that this is not the case.
I believe that a new issue problem be created on GitHub so that it can be analyzed calmly.
ya, his rangefinder orientation is 0, forward, Object Avoidance Path Planning algorithm to use = BendyRuler, AVOID_BEHAVE,1 RNGFND1_ORIENT,0 and OA_TYPE,1, RNGFND1_MAX_CM,1000 max height is 10m
For Altitude usage, he should mount the Benewake-Serial rangefinder pointing down and set the following or mount one more facing down, setup RNGFND2_xxx.
RNGFND1_ORIENT,25
OA_TYPE,0
He seems like haven’t done the first phase of tuning, the 5" propeller values are all very initial. MOT_THST_HOVER,0.432421 to me is too high. INS_LOG_BAT_OPT,0, shouldn’t it keep to 2? EK3_IMU_MASK,3, BRD_TYPE,24 (CUAVv5/FMUV5), only has 2 IMUs?
The Lidar orientation is correct, I installed it in order to avoid the obstacles. The end result is always the same for forward or down orientation. After installing Lidar the altitude is limited. Without Lidar installation and configuration the drone flies normally and very stable.
Are you using the flight stack from here or CUAV flight stack?
I think you are on your own probably if you keep the same understanding.
My understanding is, if you want object avoidance and height holding (EK3_xxx), users using the Arducopter flight stack need two rangefinder sensors. or use Baro as the default height sensing (EK3_SRC1_POSZ,1). I did this before changing EK3_SRC1_POSZ,2.
stack Developers, correct me if my understanding is not correct.
I’m using the default firmware for Cuav V5. The purpose of this drone is to carry out inspections inside pipelines that do not allow the use of GPS for positioning. To maintain the position, I installed a hereflow that has an onboard Lidar, but when I configure this Lidar or any other in any direction, the drone stops responding to the applied throttle. I continue to use the barometer as the main source of altitude.
can you post a few photos of how you mount the external peripherals? this is not your drone photos. if you are using this Hereflow both onboard sensors are facing the same direction. then your orientation should be down (25) using the CAN bus and not the serial bus. you have to mount an additional standalone rangefinder sensor forward for object avoidance.
The Hereflow is mounted downwards and I’m using the CAN bus, so much so that I’ve been getting good positioning with the optical flow. But even using the CAN bus, it is possible to decide whether to use Lidar or not, which is built into Hereflow. What I’m saying is that whenever a Lidar is set up, either from Hereflow or a forward facing Lidar I have problem with the drone’s altitude. This problem only happens when a GPS is not used, as I have another drone for external flights with Lidar that works very well. In this log that I shared, I wanted to show that it doesn’t matter if the Lidar is facing downwards or forwards that the altitude problem occurs, it is not a parameter definition problem, since I followed all the documentation correctly.
No, I don’t have this issue using Loiter or Pos-hold flight mode. I have tested after both indoor and outdoor flights are healthy, then I purposely configure no GPS, and physically remove it and repeat both the indoor and outdoor flights. I also did configure the EK3 to use lidar as high source too.
And I didn’t use the lidar onboard the Hereflow module. I am using external lidar (LW20C). So, optical flow (Hereflow) + rangefinder (LW20C lidar), for both indoor and outdoor flight.
As long as you didn’t specify RNGFND1_TYPE = 24 (DroneCAN), which I didn’t specify, it didn’t use the lidar from HEREFLOW. My RNGFND2_TYPE is not enabled. My guess the flight stack uses the orientation (forward/downward) to decide which algo to use.
I didn’t try before to add a forward lidar for the object detection and avoidance. I think the approach is to make sure optical flow and lidar height sensor work well first then add lidar forward to narrow down if the stack indeed got an issue.
