I have an indoor quadcopter with position hold and forward obstacle avoidance. At least thats my ultimate goal.
At this current juncture, ive got the position hold figured out and working fine. obstacle avoidance is more of a hit and miss.
The aircraft uses px4flow for positioning, 2 X TFmini lidar one for altitude hold and the second one for forward obstacle avoidance. No GPS as its never intended for outdoor flying. Running the V3.6.1 arducopter firmware
Issue : The forward obstacle avoidance somehow only works in AltHold and FlowHold flight modes. My understanding is the avoidance should work in all assisted or autonomous modes. However its not doing anything in loiter. I can literally fly the aircraft into a wall.
Comparing the flight performance of FlowHold, PosHold and Loiter, the positioning is the most stable in Loiter so i would like to stick with that.
PosHold drifts and FlowHold is just twitchy.
Is there anyway i can get the obstacle avoidance to work in Loiter mode? or is FlowHold the only option?
Thanks for your input as always.
That would be my understanding too.
I ran a few more tests today. While I cant totally say the obstacle avoidance is not doing anything at all in loiter.
But i cant say its doing anything either. There are random times when it seems like there is a reaction when flying into a pillar. I can still very easily fly into the pillar and the aircraft wouldnt stop me.
Or perhaps its just a timely twitch from the optical flow. If it is the latter, how do i improve the optical flow in loiter?
in altitude hold the avoidance kicks in quite strong with the aircraft actively backing off.
changing the AVOID_ANGLE, AVOID_BEHAVE, AVOID_MARGIN and AVOID_DIST_MAX param values does nothing in loiter.
The drive folder below includes my config file, flight logs and videos of the test.
I’ve had a look at the logs and the Proximity sensor health is jumping between “2” (which means “Good”) and “1” (which means “No Data”).
I’ve looked through the parameters and I think the avoidance, range finder and proximity sensor configuration is correct. So I think the two most likely causes are:
the Benewake mini sonar is not working well. Perhaps it is unable to reliably see the distance. This seems likely to me because although the RFND message is sadly missing the lidar health, we can see that during periods where the PRX.Health = 1 (i.e. No Data), the RFND.Dist1 (the lidar’s reported range) is not changing.
we have some kind of timing issue issue where the proximity sensor’s health is becoming unhealthy even though the lidar is working properly.
I will be making some more changes to the Benewake driver for 3.6.2 and as part of that I will add some extra logging to the RFND message. In particular I will add a couple of “Status” columns. This won’t resolve the problem though if it is indeed the lidar that is misbehaving. It will just provide proof that it is the lidar.
OK, I’ve found the problem and unfortunately it’s a bug in the driver (that I wrote) that leads to us losing some messages. I’ve got a fix that we will release for beta testing within a couple of days.
@rmackay9 about the refresh rate I asked you before if it was the same as the lightware, because it works fine in emulation. As for the checksum , your patch is similar to my code on Benewake I2C so it should fix the issue.
Ive given the V3.6.2 a try, theres certainly a significant improvement but its still intermittent. There are times when the aircraft dont even seem to notice the wall. The other maybe…60% of the time? The obstacle avoidance would solidly prevent the aircraft from moving forward even with maxed inputs from the pilot.
Im at least happy that it now clearly works with loiter mode. Just the reliability isnt quite there yet.
