Nooploop LinkTrack cannot be used

https://ardupilot.org/copter/docs/common-nooploop.html

Can non-gps navigation be used normally now?
After setting up according to the tutorial, I found that the flight controller could not recognize the beacon。Is my setting wrong or the beta version does not support uwb beacons?

Hi @angel12,

Can you provide an onboard log?

00000001.BIN (52 KB)



uwb测试参数.param (14.6 KB)

I put all the serial port parameters set to the same, hope to receive useful messages in them, but failed

@angel12,

There is some BCN data appearing in the logs so I think it is possible that the NoopLoop system is working. The log is very short though so the EKF doesn’t have enough time to calculate a position estimate. Do you have a longer log? Ideally try moving the nooploop beacon around so we can see that in the logs too.



Excuse me, after linktrack positioning, mp station what tips, there will be a positioning state? Or only inside the log to see?

My sd card is a little problem, I need to buy a come back again to record log. Please wait two days, and I’ll upload longer log.

1 Like

I recorded logs, I opened the base station, but I didn’t see in the log d0). D1, d2, d3, is this why



00000004.BIN (868 KB)

00000005.BIN (748 KB)
I carefully check, can only see a straight line, is this normal

00000008.BIN (960 KB)




My flight control logging base station location, but my ground station does not display the location, this is normal.

@angel12,

Could you try setting these parameter values?

  • EK3_SRC1_POSXY to 4 (“Beacon”)
  • EK3_SRC1_VELXY to 0 (“None”)
  • EK3_SRC1_VELZ to 0 (“None”)

I think this might solve the issue. I’ll update the wiki, sorry about that.




I’ve tried, but the result is bad. BCN_ORIENT_YAW this value seems to need to be very accurate, BCN_ORIENT_YAW accurately, log will record the beacon position otherwise will only record in a straight line. I tried many times, only a few times can see in the log to do data, d1, d2 and d3. Although can see logging beacon location, but also won’t appear the plane location on the map.

@angel12,

Can you try and produce a log with the EKF3 parameters set as described above? With that we can hopefully see why the EKF is not happy.

It might also be good to set LOG_DISARMED = 1 and LOG_REPLAY = 1 so that we can replay your logs through EKF on our local machines and hopefully reproduce the problem.

The Beacon data appears to be arriving reliably at 10hz so this is good.

I have been able to fly now, but every time need to restart many times to locate, what reason is this? Seems to be related to luck. Can I ask, what kind of circumstances can position every boot can appear

Hi Randy, sorry for the disturbance. I’ve been testing this UWB system for a while now and I’ve encountered similar problems.

Here’s what I’ve tested and what I know.

  1. Autopilot board: CUAV v5 Nano, running AC-4.1.2;

    LinkTrack LTPS (small tags with ceramic antenna, basically the same as the larger ones);

    Connected to Serial 1 with good conditioned silicon cables and properly made connectors, at 921600 baud rate and all the settings according to the official Wiki.

  2. I’ve followed the official guide step-by-step and no luck. Not only won’t the position converge to the test area on the map, but the GCS will also constantly pop out “PreArm: Bad GPS Position”.

  3. I’ve tried the work-around method by attaching an Arduino Nano between the interface, it works for some very rare cases and for 99% it will fail.

  4. I’ve also tinkered with the EK3_SRCx_POS/VEL set of parameters as well as EKF source switching, still no luck. The EKF source switching using a knob works perfectly fine on my system and I can in fact switch between a GPS based localization and an optical-flow based loitering/PosHold. I put the beacon at EK3_SRC3, and EK3_SRC3_POSXY = 4, EK3_SRC3_POSZ = 1, the EK3_SRC3 velocity sources are all set to zero and I’ve turned off velocity fusing, i.e. EK3_SRC_OPTIONS = 0.

  5. The NoopLoop system and the tags work just fine, and I can see them working properly in the NAssistant GUI. I’ve also noticed that the Tx LED of the LinkTrack is blinking as it should, otherwise the ArduPilot shall be sending Setting_Frame0 to request Anchor States from the module. Moreover, I can see in the log there are properly recorded Beacon data, namely the BCN.D0~D3.

  6. I’ve done some test and directly modified the ArduPilot ource code to print the BCN.D0~D3 through MAVLink Messages and display on Mission Planner, and it shows correctly.

  7. I’ve tried to set the LinkTrack into “fake-GPS” mode to trick the autopilot and it will make a great 3D fix but the EKF won’t accept it, hence no effective loitering. But I know this is not the “canon” implementation.

  8. I’ve tried to tune down the baudrate in the corresponding serial, as well as increasing the filter factor hoping to get a more stable reading but it’s still the same.


It seems that there is something causing the system to get stuck at the EKF check. I’ve tried my best to dig deep into the source code but I still cannot locate the problem.

Attached is the log file [URL: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.] (I had to share it using OneDrive cuz it exceeds the file size limit even after compressing) and some snapshots. I’ve doubled the LOG_FILE_BUFSIZE to 160 and enabled LOG_REPLAY and LOG_DISARMED, as per the suggestions you mentioned before in this thread. I hope this may help the team understand this situation better, and hopefully in return help me out of this situation.


Fig.1 BCN fields.


Fig.2 NAssistant snapshot

I look forward to hearing from you soon, thank you!

@rmackay9 I am facing the same issues as Wesker here. Would you be able to look at both our logs to see what is going on. I have attached a shorter log of a bench test with me hand moving the craft around the flying area as well as a static position log here WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

I hope you could help us get this working. I am willing to put in all the testing time required to get it tested and working with your advice for the greater good of other arducopter users.

1 Like