Aerotenna uLanding - Extensive Issues


My goal is to use the Aerotenna uLanding-C1 for the purpose of maintaining AGL and improving landing performance.

Current Configuration:
Pixhawk 2.1: ArduPlane V3.8.0
GCS: Mission Planner 1.3.49 build 1.1.6410.20232
Altimeter: Aerotenna uLanding-C1 (Serial)

I have the uLanding connected to Serial4 (GPS2) of the Pixhawk 2.1.
SERIAL4_PROTOCOL: 12 (uLanding Parameter value)
SERIAL4_BAUD: 115 (uLanding default Baud Rate)

The only parameter I have changed regarding the range-finder functionality is:
RNGFND_TYPE: 11 (uLanding Parameter value)
I have tried adjusting various values related to the upper and lower bounds, but none have seemed to affect readout. See below.

Unexpected Behavior:
Upon connecting Mission Planner to the Pixhawk, SonarRange reads “0”. If I move the altimeter around, 1-3 three similar windows open (??), and the SonarRange value is populated. In most cases, a value of 6.35 (cm) is displayed regardless of orientation and obstructions before the altimeter. On occasion, sporadic (erroneous) values are displayed.

I was hoping someone with a similar configuration utilizing the uLanding might give advice on the proper configuration (parameters) or known issues with my configuration.
Current theories:

  • PH2.1 cannot sustain 115 kbaud on Serial4? When I tried lowering to 9600 baud, the value reset itself to 115 kbaud on next startup and connect cycle.
  • Some parameter related to the abundance of laser analog/PWM altimeters is interfering with the value?

See below for an example of the issue (including mystery window) and a copy of my parameters.

ForumExport.param (14.0 KB)

I have reproduced what you are seeing Evan. It appears the arducopter driver for the unit is crap. If it get it working I will share it.


The driver was contributed by Aerotenna - it might be worthwhile to get in touch with them directly ( I suspect that there aren’t yet many users or devs with the uLanding, so help in this forum might be a bit slow unfortunately.


The issue was tracked down to a change in the uLanding firmware. I made a forum post on their site, to which they responded with a potential solution:

My stopgap solution was to modify the AP_RangeFinder_uLanding.cpp to implement the changes made to Aerotenna’s implementation (their own branch of Ardupilot). See the uploaded file (.zip containing .cpp) for the working modification.

I’m glad to see that it appears the Ardupilot community has made the necessary adjustments to the Master branch firmware fairly recently (14 days), and it now detects the version number of the attached uLanding sensor in the same manner as the Aerotenna implementation. The quick patch I made did not do this, and so would only work with the current uLanding firmware. I can, however, say that it also works for the uSharp patch avoidance radar (the two sensors return data in exactly the same format). (1.4 KB)

1 Like


So I finally found a need to upgrade to Plane 3.8.2 - the latest version after the fix to the ulanding driver - and tested out the rangefinder.

. . . .

Well, back to square one. The behavior of the sonarrange output has reverted to that originally demonstrated.
For testing completeness, I reverted my Pixhawk 2.1 to the custom firmware I previously built (see above post for file, requires compilation), and found that it still functions.

I’ll work on compiling the same modification with 3.8.2 as a base, to see if the fix still functions with the latest Master updates. The associated header file would likely need to be rolled back as well (to 3.8.0 status).

My apologies for the potentially early celebration.

can you raise an issue in github for this?

1 Like


I created an issue entry here.
This is my first time entering an issue on the Ardupilot Github, so please give me a quick reprimand in reply to the linked issue if there’s anything obnoxious about my entry (in spite of reading the issue guidelines).

Thanks very much Evan, greatly appreciated.



Sorry about the response delay; I mentioned it in the issue, but it looks like the updated uLanding driver just hasn’t made it into the stable branches yet. Basically, the update to Plane 3.8.2 ended up reverting your build to the old uLanding driver, hence the issue showed up again.

Ah, thank you for the clarification.

I wasn’t clear on the release process, so I had assumed it was implemented, as the updated code was present in Master. Upon further review, 3.8.2 was released on the 11th of last month, whilst the change to the driver was made 11 days later . . . Oops.

I’ll see if I can’t get Master to compile for Arduplane as it is, to test (future) functionality. Luckily for me, it would seem the latest build is passing [3.8.3 Beta 1], per the ReadMe tags (build was failing as of my last post). If nothing else, I’ll try injecting the updated drivers to the current, stable 3.8.2, and see if it functions properly.


I don’t know about your rangefinder. However I can tell you about mysterious windows. Which I too cannot get rid off.
They are somehow related to gimbals.
The day it first appeared for me was the day that I first tried to setup a gimbal inside of mission planner.
I think it is sort of a test window. However it is definitely buggy as it pops up at every restart now, some times up to 3 of the same window. Even thought I have removed all mavlink to gimbal related stuff from all my UAVs.

Compiled ArduPlane (PX4-v3) from source code in Master last night.
Verified that the uLanding altimeter does indeed work with the updated driver.

So it should be a matter of time until the next release (alternatively, using 3.8.3 Beta 2).

1 Like

can you confirm that ArduPilot master works correctly for you?

ahh, sorry, I see you’ve already answered that! I should have read ahead

1 Like

I’ve pulled the changes from master into 3.8.3beta3, which is building on the build server now
please check it in a few hours and make sure it works
it should be git hash 98c2f233719337112683d7dea00ff9f165bdffa7