@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? ArduPilot/CANBUS - Gitter
Hi Pavel,
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?
Cheers,
Edwin
Hi Edwin,
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.
1 Like
Hi Pavel,
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?
Cheers,
Edwin
1 Like
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.
1 Like
Hi Pavel,
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.
Cheers,
Edwin
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.
Any updates on the driver progress?
Still waiting.
Any update on this issue ? Having same problem here
Thank you for registering it here. We are currently unable to allocate resources for the task. We will be posting updates here as things progress.
This may be a non-issue at this point. Latest master ArduPilot has an added parameter that allows selection of boot time out from zero to 10 seconds to allow accessories to fully boot before the AP. Has worked well on all of my units tested.
RB
1 Like
Has any update been made? Like the other above I am also have this issue on a CUAV Cube flight controller. I was able to add in a boot delay on arducopter 4.0 to reliably enumerate the compass. However it would be nice if the compass booted quicker