Hi all,
I am new to ArduPilot and Mission Planner. I have setup an RC vehicle with a Cube Orange and 2 HerePros.
My goal is to setup GPS for Yaw with 2 HerePros. I have updated to the latest firmware on the Cube and the HerePros.
I have followed the guidlines here [
As can be seen from the below screenshots, there is an issue with the EKF variance.
I have read through the existing posts i can find on the topic but i cannot find a solution.
In the most recent tests, the Yaw(deg) was wondering a lot over time, so i guess this is not working.
In my setup i have calibrated the accelerometer and have disabled the compass.
When i use GPS_AUTO_CONFIG = 2, it does not automatically configure the GPS units. So i set this to 0 (zero). However when i do this, i am not sure how to configure the GPS directly. I noticed with GPS_AUTO_CONFIG = 2, MP would set the GPS configs to 17/18. This has me confused.
My mistake. I forgot about the CAN setup being slightly different.
Set 22/23 on the Cube’s parameters and use auto configure option 2. It works as advertised (meaning it will set the DroneCAN nodes’ internal parameters to 17 and 18).
@zoran, confirm you’re outside with a clear view of the sky?
On the CAN modules, you have both SERIAL3 and SERIAL4 selected as GPS. Only one of those is correct, but I’m not sure which. That’s a potential source of error (and why I recommend autoconfig rather than getting in there and mucking about yourself…but once you’re no longer on defaults, autoconfig can have trouble, too!).
You might also try BRD_BOOT_DELAY=3000. Sometimes it helps to allow time for the CAN nodes to boot before the autopilot. I’m less confident that this is actually you your problem.
I looked for a message in your log like “EKF Failsafe Cleared” and didn’t see it. On my rovers, I can’t arm until I see “EKF Failsafe Cleared”. Attempts to arm before “EKF Failsafe Cleared” are just met with a simple “Failed to ARM” without any explanation why.
I believe (although I don’t know for certain) that EKF Failsafe Cleared message is displayed after the GPS heading becomes available to the autopilot. Sometimes it takes 15 secs after bootup and sometimes it takes 15 mins. (I think it takes longer when the rover has been powered down for several days).
Hi @Yuri_Rage , apologies for the late reply. I am travelling today and tomorrow and don’t have access to the rover. During my latest test i was actually indoors. So i can definitely move the rover outside to test.
I was informed that setting FORMAT_VERSION,0 would restore the HerePros to their default configuration, however, i am not sure if this has worked. Please let me know if this is correct or if there is another way to achieve the default configuration.
The only thing i modified after “restoring” these is the CAN_NODE,124/125 on each HerePro.
The latest results are with autoconfig = 2, so the Cube should have set the correct parameters on the HerePros.
I will try BRD_BOOT_DELAY=3000 on Thursday.
Thanks heaps for your support so far.
Hello @Christopher_Milner,
Thanks for your insight. I will look out for “EKF Failsafe Cleared” in my messages. As my latest testing was indoors, I’ll see if the messages capture this information when i take the rover outside. This should hopefully improve the GPS signal and provide the GPS heading.
Hi @Yuri_Rage,
I tested the rover in my backyard with the latest configuration. The Cube did not get a GPS Fix. I left it for quite some time to see if it needed longer to achieve a fix, but no luck.
I also did a full accelerometer calibration instead of simple and it said it was successful.
GOS2 was also changing to dgps but not consistently.
I also added 3000 to the BRD_boot_Delay but not in the latest uploaded param file.
Disallowing autoconfiguration of the CAN GPS modules is doing you no favors. I confess I don’t really know what the root cause is, and I don’t have any HerePro modules to test on my own. The Here3+ modules I’ve tested with Rover 4.2.3 work just fine.
This issue has nothing to do with IMU calibration. You can’t enable AUTO mode because your primary yaw source is missing due to the GPS config issue. I updated the topic title to reflect the issue more accurately.
I’m beginning to wonder if you have a version mismatch between a slightly dated (but still valid) Rover firmware and much newer AP_Periph firmware on the nodes. It might be interesting to update to the 4.4-beta branch on the autopilot to see if this resolves anything.
@tridge, I know there have been significant updates to the moving baseline parameter set and underlying codebase. Any insight as to the issue at hand?
Hello @Yuri_Rage,
I appreciate your support with this.
I updated the rover firmware to 4.4-beta and have set the auto_config to 2 (CAN). I then setup everything as previously and the GPS is not able to get a fix.
Is it possible that these HerePro units are just not working properly? CubePilot_Config_08102023_Rev_001.param (14.9 KB)
If I get a chance tomorrow, I will try and reproduce on the Here3+ modules I have. Since it doesn’t appear to be firmware/version specific, that may be a valid test. Unfortunately, I think we are on very different time zones, so our conversation will likely be a bit slow-paced.
You might share the param files from each module as well. The boot message dumps aren’t really all that useful.
Thank you @Yuri_Rage, I greatly appreciate the help.
I don’t mind the delay with our conversations. This project has already taken a lot longer than i had hoped.
Please find attached the HerePro param files. The latest testing has relied on these being configured in their default configuration and allowing the Cube to configure them through Auto_Config = 2.
Problem seems absolutely reproducible on Here3+ modules. I spent a very long time today trying to narrow it down, even using u-Center to manually configure using CAN passthrough. u-Center showed good fix and data at appropriate rates, but the Here3+ remained unaware of its own GPS unless it was configured as GPS_TYPE=1 (with type 9 set on the autopilot itself).
It seems as if setting GPS type 17 or 18 on a DroneCAN node causes the GPS to not be recognized by the CAN node.
GPS types 22 and 23 were set on the autopilot during testing, but the GPS modules were never detected by their own nodes, so no data was passed along to the autopilot.
I updated the nodes to the latest (showing 1.10.D5ACDDDC), and I’m using Rover 4.4-beta7 on a Cube Orange+.
Same results on a QioTekH743, which isn’t really surprising, seeing as the problem appears to lie in the nodes and not the autopilot.
Hi @Yuri_Rage,
This is what i was seeing also. Only when type 9 was applied or I moved away from CAN (disallowing autoconfiguration) did the Cube recognise the GPS.
Fingers crossed there is a way to resolve this issue. And thanks again for your time with this.
I’m sure there’s a resolution to it, and I’m reasonably certain that it will require an update to the CAN node firmware. I’d dig into it myself if I had the time, but I spent a ton of that already today investigating.
In the meantime, I’m looking into using CUAV’s new dual antenna setup for a new rover build of mine. It’s about the cost of a single F9P module and boasts moving baseline capability on a single board.
