First post but I have been reading and searching posts for months as I get my feet. I’ve reached a point where I need community wisdom. Thanks in advance for grace if it turns out I’m doing something boneheaded.
I wrote about two pages on my issue and then decided I need to start with the very short version:
Starting from a working rover with working GPS’s in GPS_type=9, after attempting a GPS yaw configuration according to the ardupilot instructions, I’m unable to get even regular type 9 to work. I’ve restored default parameters and started my configuration from scratch and still can’t get the here3+ to work again in gps_type = 9.
I’m hoping someone can shed some light on the configuration of the here3 itself, and if I’m really lucky, can confirm a working GPS yaw setup using these units.
What I suspect is going on in my current near-brick state is that configuring the GPS yaw settings in ardupilot causes a configuration change within the here3+, but changing the configuration back does not reset the configuration in the here3+. I can’t find any documentation about the here3+ parameters accessed under the CAN menus – can anyone point me to those? Unfortunately, I didn’t think to capture these in my baseline configuration – and I’ve now put both here3+ in this weird state where the GPS doesn’t work. Can someone with a here3+ take snapshots of those configurations? Any useful advice or reference materials?
Thank you in advance for any help!
Misc details:
Both units are working on CAN – the status lights work, and the compass readings work/compasses are visibile under compass priority
Both units updated
Tried both can ports, with only one unit connected or both
Tried all permutations of GPS#_can_ovride
Tried all permutations of GPS_auto_switch and GPS_auto_config
Rover picture and controller side component picture for interest.
Thanks for engaging on this Yuri, I really appreciate it. I’ve read a lot of your posts and advice for others… my setup is actually a product of concluding after reading your exchanges with some other newbies I needed to start with something simple to wade into ardupilot before I go for something more complicated like the zero turn mower. This is really supposed to be a learning platform and my goal was to not post 100 times with questions I should be able to answer on my own. I know you advise against this gps unit in favor of 3x simplertk2b with better antennae, but I figured this hardware would represent an easier starting point I could graduate from.
I’ll grab the parameters this evening. Once I started having issues I saved religiously so I have a “last working” a “next broken” and a “now” I can post.
If you still have issues, I suspect it may have something to do with mucking around in the Here3+ (AP Periph) parameters that work straight out of the packaging. I’ve never changed them. Ever.
I’m nearly certain there isn’t an auto-config issue for M8P GPSs in the ArduPilot firmware. (EDIT, there is a CAN-specific issue, see follow on discussion).
I reverted the changes I made to the 1 gps. I only changed:
Value
Stock
Modified
Returned to stock
CAN_NODE
0
124
0
GPS_TYPE
17
9
17
after a reboot the GPS is still not visible.
Also tried disconnecting and same with the 2nd gps, which I never touched the parameters via CAN on. Still no dice. At this time I’m trying to simplify by going back to the single GPS configuration (before trying to get GPS yaw working), so the current parameters file is consistent with that (attached).
The device continues to be visible on CAN and in the compass screens, but no signs of GPS life. Not in the CAN GPS order screen, and nodeID is not being populated (which it did correctly before attempting the yaw configuration).
Should you have the patience to recommend anything further, I won’t make any changes other than those requested. I know going back to type 9 was beyond the recommendation but I went in that direction shortly after my post…
When you say, “not visible,” what exactly do you mean?
Are you seeing “No Fix” or “No GPS” in the HUD?
Also, are you rebooting via software? Or removing and reapplying power? Sometimes you ought to completely remove power after making significant changes to the low level parameters.
Might be worth trying BRD_BOOT_DELAY of 1000-3000. Sometimes that helps.
GPS_TYPE 17 is always wrong for this config. It ought to be 22 or 23 for a moving baseline config using CAN (or 9 for DroneCAN GPS).
When I say not visible I mean:
“No GPS” in HUD
“EK3 waiting for GPS config Data”
No gps shows in UAV can order
no GPS_CAN_NODEID1 or to autopopulating
(see hodgepodge screenshots attached)
Note the devices are visible both in the compass screen and the dronecan screen. If I plug both GPS’s in they are both visible. I can do a compass calibration with all 3, and talk to them both on the CAN screens. Just no signs of GPS.
EDIT: for power cycles I’m doing full power cycles removing power. I started doing that after observing the uptime values from the CAN devices - rebooting the cube does not reboot the powered can devices. So full reboots. Trying your suggested parameter now.
Second edit:
For the GPS type 17 - that is not a value i’ve ever set on the cube. That, ironically, is a default value for GPS type in the here3+ setting, which much either mean something different, or something internally for how the here3 talks to the GPS chip that’s on it. This value is what got me thinking the ardupilot config might drive a configuration item on the here3+, since that value might coorelate with whatever the here3+ is running of course not using CAN internally to talk to its GPS… end ramble.
Expanding on my gps type comment a little bit - I vaguely recall that the Here3+ is actually something like a flight controller perhaps running ardupilot based firmware on it. If that’s the case, the idea that that type 17 might be Ublox moving base rover might make sense, because to the here3+ firmware, the gps type wouldn’t be can. When I edited that parameter my reasoning was… Maybe setting type 22 and type 23 for ardupilot on the cube was supposed to flip one of the here3+'s to be type 17 and the other to type 16, and if both ended up rovers with no base… maybe I’d find myself in the situation I’m now in. Alas, editing that in the here3+ to 9 didn’t resolve this when I tried it, although I haven’t tried that again since the advice not to mess with it (in combination with your other recommendations). If i hit a dead end perhaps that’s where to go, particularly if someone is able to read the here3+ parameters on CAN and we determine that type value is != 17
I think I know where we are going wrong, and it’s all down to miscommunication.
On the Cube Orange, you need to set:
GPS_TYPE = 22
GPS_TYPE2 = 23
GPS_AUTO_CONFIG = 2
GPS_AUTO_SWITCH = 1
On the Here3+ modules themselves (AP Periph is using onboard UARTs for communication within the module hardware; it’s only CAN for external comms to the autopilot):
GPS_TYPE = 1
And then get out of the CAN parameters screen. You really don’t need to be in there!
I just so happen to have a bone stock Here3+ that’s never been connected. Here are its AP Periph parameters fresh out of the package (consider using these on your Here3+ modules if you have more problems): Here3-Default.param (1.3 KB)
Most likely, when you set GPS_AUTO_CONFIG=2 and GPS_TYPE/2 to 22 and 23 on the Cube, it will reconfigure one of the Here3+ modules to GPS_TYPE=17 and the other to 18. But that should be transparent to you.
Lastly, if you don’t want to use a moving baseline config, set:
GPS_TYPE = 9 on the Cube
GPS_TYPE = 1 on the Here3+
You can probably get rid of any boot delay greater than zero now.
I can also confirm that there is likely a bug in the CAN auto configure routine that does indeed affect GPS_AUTOCONFIG=2 and reversion to GPS_TYPE=9 from GPS_TYPE=22 or 23.
Well you beat me to it, I was going to retrace how I got here and figure out the issue to document for developers or instructions to document for the here3+ documentation to do my part… though I wouldn’t have known where to direct it.
I appreciate the help. It’s funny how you can stare at something for hours and miss the obvious thing. Now that I reread my posts it’s clear when I kept talking about going back to type 9 on the here3, it’s obvious the here3 would need to be type 1 if anything! Also, lesson learned: save all configs out of the box for reference.
I’ll circle back confirming I got the GPS yaw working when I’m back at the hardware tomorrow.
I appreciate the feedback xfacta re: device placement. For this setup so far the transmitter and telem performance are more than adequate - my principle concern has been gps performance. But I appreciate the feedback for when I get to a future setup.
I will note the greatest performance issue I had with this approximate setup is the gps nearest the telemetry. In a prior arrangement, the telemetry antennae coming out near the GPS would degrade the GPS connectivity. I could move the telem closer and watch the GPS lose the lock indoors. With this orientation and spacing the issue is not noticeable.
All of this is to say:
Keep interference away from GPS antennas
Space out your antennas
Metal plates: good when oriented as a ground plate for GPS, bade when oriented against the plane of your omnis
And for my setup: I accept the compromises for the simplicity of the test bed… and when I’m confident I don’t need a sled/pipe to move between rovers and my desk quickly, I’ll optimize on the rest!
Unfortunately my attempts to get these going into GPS yaw are not succeeding.
On first reboot the GPS’s both showed but went 20 minutes without getting to GPS fix. On reboot, they stopped showing and were in the state observed previously with No GPS and no can node ID being populated.
I’m thinking it may be best to revert to type 1 like last night to get these both working normally and just run in the field without GPS yaw for a bit before coming back to this… Attaching parameter files for cubes and GPS’s if you’re still interested.
I don’t have any immediate solutions and am away from my computer for a while. I wonder if you have some wiring/interference issues that compound things?
It’s not impossible that it’s interference or wiring, though both GPS’s have pretty good performance in this configuration in type 9, so I don’t suspect the interference issue. When the GPS’s weren’t locking I did move them outside to give them the best odds.
For wiring, the only real potential issue I see is the single vs separate can bus question. IIRC the here documentation implies separate bus, the ardupilot documentation is clearly same bus. I’ve been doing same bus presuming the GPS’s needed to be on the same bus to talk to eachother.
I think I’m going to go back to type 9 and compass yaw with all of the compasses calibrated and move forward with tuning the rover this weekend and seeing how it does. I’m still learning everything and it’s possible I’ll catch something in the future I’m not catching now. I’ll remain willing to try ideas and will come back to it on my own after some other progress - but I’m at least past the ultimate frustration of non-functioning GPS’s.
