@rbachtell and I are experiencing the same issue with our Cube 2.1 flight controllers on ChibiOS with the Zubax GNSS. Randy is running the latest master of AP, and I’m running 3.6.5. When we power up the drone via battery power and the cube power module, the Zubax’s on-board compass will not initialize. If we boot up the cube via USB power, and then switch over to on-board power, the Zubax compass initializes successfully. Any idea what’s going on? I have an impending deadline to deliver 2 utility inspection drones and would love to have this sorted as soon as possible. Cheers!
Hi there, this is definitely not related to Zubax GNSS itself, because it broadcasts its magnetic field measurements regardless of the power-up sequence or any activity of the autopilot whatsoever. The problem is within ArduPilot, which is actually unknown to us. I know that its UAVCAN implementation is being constantly updated and upgraded, so there might have been some sort of regression. Have you tried asking for assistance in this chat room? https://gitter.im/ArduPilot/CANBUS
We are having a [perhaps identical] issue; our GNSS2 doesn’t get enumerated as a compass by ArduPilot running ChibiOS. From a cold boot, the GNSS doesn’t get detected as a compass, but if we then perform a soft reboot of the autopilot without touching the GNSS, the compass gets detected correctly.
We have other CAN devices on the bus, which boot instantly with an entirely static configuration, and if we use uavcan_monitor to compare the uptimes of the various devices, we see that the GNSS2 reports exactly ten seconds less uptime, implying it took ten seconds (more) to boot up.
ArduPilot has a five second delay to allow for UAVCAN devices to initialise, but it seems that the GNSS2 is still taking too long (I’m guessing the issue might be that the ChibiOS versions of AP, being faster, start this clock running a bit sooner than NuttX versions?).
From reading the documentation, it seems like most of the time is just spend in the boot loader’s waiting state. Is there anything that can be done to speed this up?
The ten seconds delay might indicate that the device performs a dynamic node ID allocation after powering up; consider configuring a static node ID (the parameter is
uavcan.node_id). If that is already done, ignore this suggestion.
The optimal approach as I see it is to make ArduPilot tolerate slow-starting nodes, since the 5-second boot-up assumption may be hard to meet by some other hardware units. If that is impossible, we could release an updated version of the firmware for Zubax GNSS with a reduced boot-up time, but the ETA for such a release is a bit difficult to define atm.
Yeah, it’s already on a static ID.
I understand you also removed the parameter to support static definition of (CAN) bus speed in new firmware. What was the reason for this? Not sure how much of the startup time is spent auto-bauding.
I would argue that a five second waiting period is unacceptably long for a device designed for use on aircraft: in the event of a CPU reset, by power glitch or software issue, the sooner the device returns to normal operation the greater the change the system has of recovering.
What is involved in flashing the bootloader on the GNSS2?
Edwin, we have registered this issue internally and there will be a firmware update soon. The bootloader can be updated using the Zubax Dronecode Probe, ST-Link, or any other SWD debugger.
Just to confirm: we’ve now tested against ArduPilot firmware which has been modified to increase the boot timeout to ten seconds. In this case the compass is reliably enumerated correctly after a cold boot.
Thanks for the confirmation, Edwin.
Pavel, do you have a timeline for the firmware update as we are trying to meet a deadline for delivery
Our best estimate at the moment is end of April 2019.