Hello guys. I’m having issues with the Teraranger tower evo 60m by Terabee, four sensor version. Avoidance works nice in manual mode (AltHold, Loiter) but when I try to use it with bendy ruler the drone just stays static in the air. I’ve been troubleshooting this with Terabee andI think that I know why this is happening: The Teraranger tower evo reports the distance of each of the eight sensors as a 20 byte message (see the first attachment), where each one of the individual distances acquired by the eight modules is a 16 position binary number (between 0 and 65535). the problem is that when a rangefinder module is not present or when a module doesn’t detect any obstacles it sends a 1 (0x0001). My theory is that ardupilot filters out this value when using avoidance in manual modes but with bendy ruler it takes it as 1mm, which would explain why the vehicle stops as soon as it enters in any of the guided modes.
I was using arducopter 4.0.7.
I had the OA_BR_TYPE parameter set to 1 so I didn’t give it the option to fly up or down.
The OA_X parameters were left with their default values.
I no longer have the vehicle in my hands so I can’t attach the parameters, but I’m sure I could recreate the problem in any other arducopter vehicle if necessary, since I know I’m not the only one with this issue ( ).
The second attachment is a screencapture from a terminal software. This is what the Teraranger tower evo sends when there are no obstacles around (except for sensor 7 that detected something at 9.18 meters).
Could we try and fix this issue and how could I help?
Hi @Serch,
The problem you are describing, we first noticed in RangeFinders. I never looked at the problem in TeraRanger’s driver, but you are right, it is there as well (as I just checked).
Basically, the problem was that we weren’t checking the validity of the readings for a few drivers before sending them to the obstacle database.
The good news: I have fixed this issue in Master, and therefore Copter 4.1 Beta should work just fine for you (please let me know if you can test and confirm the same).
The other good news is, that we have backported the fix to Copter 4.0 also ( just a few weeks back). But I don’t think we have any more 4.0.x releases in store so it isn’t immediately available to you, so if you can make a build for yourself, the latest Copter4.0 branch should work just fine for you: https://github.com/ArduPilot/ardupilot/tree/Copter-4.0/
Sorry for the inconvenience
By the way, you say you are using Copter 4.0.7, but the parameter “OA_BR_TYPE” (as mentioned in your post) is only available from 4.1 onwards
Oh, thank you very much. About the OA_BR_TYPE parameter I just assumed it was on 1 since I didn’t change it but now I guess it wasn’t even present when I tested it, I don’t have the vehicle anymore so I reproduced the problem from my memory
As soon as I have another vehicle available for testing this I will let you know.
Do we have a probable release date for Copter 4.1 stable?
