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)
Messages:
8/10/2023 3:11:34 PM : Throttle armed
8/10/2023 3:04:43 PM : PreArm: Hardware safety switch
8/10/2023 3:04:12 PM : PreArm: Hardware safety switch
8/10/2023 3:03:41 PM : PreArm: Gyros inconsistent
8/10/2023 3:03:41 PM : PreArm: Hardware safety switch
8/10/2023 3:03:26 PM : EKF3 IMU2 tilt alignment complete
8/10/2023 3:03:26 PM : EKF3 IMU1 tilt alignment complete
8/10/2023 3:03:26 PM : EKF3 IMU0 tilt alignment complete
8/10/2023 3:03:25 PM : AHRS: EKF3 active
8/10/2023 3:03:24 PM : EKF3 IMU2 initialised
8/10/2023 3:03:24 PM : EKF3 IMU1 initialised
8/10/2023 3:03:24 PM : EKF3 IMU0 initialised
8/10/2023 3:03:22 PM : RCOut: PWM:1-14
8/10/2023 3:03:22 PM : GPS 2: specified as UAVCAN1-125
8/10/2023 3:03:22 PM : GPS 1: specified as UAVCAN1-124
8/10/2023 3:03:22 PM : AHRS: DCM active
8/10/2023 3:03:22 PM : ArduPilot Ready
8/10/2023 3:03:21 PM : Beginning INS calibration. Do not move vehicle
8/10/2023 3:03:21 PM : Barometer 2 calibration complete
8/10/2023 3:03:21 PM : Barometer 1 calibration complete
8/10/2023 3:03:19 PM : Calibrating barometer
8/10/2023 3:03:19 PM : RCOut: Initialising
8/10/2023 3:03:19 PM : CubeOrange 004E0026 3131510D 31363832
8/10/2023 3:03:19 PM : ChibiOS: 17a50e3a
8/10/2023 3:03:19 PM : ArduRover V4.4.0-beta7 (f3d3a226)
8/10/2023 3:03:19 PM : RCOut: Initialising
8/10/2023 3:03:19 PM : CubeOrange 004E0026 3131510D 31363832
8/10/2023 3:03:19 PM : ChibiOS: 17a50e3a
8/10/2023 3:03:19 PM : ArduRover V4.4.0-beta7 (f3d3a226)
8/10/2023 3:03:19 PM : RCOut: Initialising
8/10/2023 3:03:19 PM : CubeOrange 004E0026 3131510D 31363832
8/10/2023 3:03:19 PM : ChibiOS: 17a50e3a
8/10/2023 3:03:19 PM : ArduRover V4.4.0-beta7 (f3d3a226)
8/10/2023 3:03:19 PM : Initialising ArduPilot
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.
Thanks again.
CubePilot_Config_08102023_Rev_001.param (14.9 KB)
HerePro_Base_Config_08102023_Rev_001.param (1.6 KB)
HerePro_Base_Config_08102023_Rev_001.param (1.6 KB)
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.
Possibly related issue: AP_GPS: DroneCAN GPS_AUTOCONFIG does not revert from moving baseline to standard · Issue #24272 · ArduPilot/ardupilot (github.com)
@rmackay9, @tridge, @proficnc, requesting your help, please.
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.
Thanks @Yuri_Rage,
I look forward to hearing about your results with the new CUAV system. We may need to explore another solution, so it would be great to get your insights on this.
There’s no good reason why DroneCAN F9P modules shouldn’t produce outstanding results. But I think we’ve found a bug (or a confusing config issue).
I wouldn’t use my own Here3+ modules (M8P based) for a moving baseline config on a real vehicle, but it should be entirely possible, and they suffer the same apparent issue during bench testing. I will keep the bench test rig intact while we await resolution.
I’ve appealed for help in the relevant Discord channel as well and will keep you informed if discussion there moves things forward.
No response so far. @amilcarlucas, any suggestions or other cages to try rattling?
I know the Here3+ isn’t the best hardware for the use case, but the HerePro should work quite well…and it doesn’t seem to work at all as a moving baseline configured module.
Are both modules Here3+? Have you tried contacting Hex/ProfiCNC ?
@amilcarlucas, the OP’s problem is with a pair of HerePro modules, but it seems to extend to my pair of Here3+ modules as well (used for testing here, as it’s what I have on hand, and the issue seems reproducible).
I previously raised this issue, but I think the problem is worse than just reverting back from moving baseline, as no one seems to be able to configure Here GPS modules for yaw.
I tagged Tridge, Randy, and ProfiCNC in a post above (and I think in another related thread from this summer), and I recently made a brief inquiry on the #hardware Discord channel. While I’m sure it isn’t personal…feeling a bit ignored here.
I can not test, sorry. I advise you two to ask profiCNC again.
Understood, Amilcar. I just know you’re a bit more active in discussion here.
@proficnc, requesting your assistance, please.
Replied to a relevant topic on the CubePilot forums:
Dual HerePro (GPS for yaw) with no yaw and satellite - HerePro - Cubepilot
Due to complete lack of response by the AP development team and CubePilot alike, I’m afraid all I can do is recommend that you return these expensive paper weights and use a more proven solution like dual Zed-F9P serial breakout boards like those available from Sparkfun or ArduSimple.
Perhaps that sounds harsh. If it does, it’s probably taken in the correct context.
@Yuri_Rage @zoran I am looking into this issue. Please note that Here hardware is maintained by CubePilot not Ardupilot. This is not the correct forum for discussion. Its best to move to CubePilot forum for further discussion. I have created a post there to continue looking into this issue. HerePro Alpha module Moving Baseline issue - Cubepilot
To be fair, it was hard to know whether this was an ArduPilot or a CubePilot problem. I think we’ve narrowed it to a CubePilot problem, and, as you saw, I attempted to both tag an appropriate username here and move conversation to the other forum site. Both went unanswered for several days.
Thank you very much for taking a look.
Hi @Yuri_Rage and @bugobliterator, thank you both for your support with this. I will keep checking this space for any updates and will also keep trying on my end.