ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.96k stars 17.49k forks source link

AP_GPS: DroneCAN GPS_AUTOCONFIG does not revert from moving baseline to standard #24272

Open yuri-rage opened 1 year ago

yuri-rage commented 1 year ago

Bug report

Issue details When using AP_Periph GPS modules (Here3+) with GPS_AUTOCONFIG=2, GPS_TYPE=22, and GPS_TYPE2=23, ArduPilot will correctly set the periph node GPS types to 17 and 18.

However, if the user subsequently reverts to GPS_TYPE=9, ArduPilot will fail to detect the periph GPS until it is manually set back to GPS_TYPE=1 within the CAN parameter list.

Discuss topic: https://discuss.ardupilot.org/t/here3-issues-after-failed-gps-yaw-attempt/103589/

Version Rover 4.2.3, Copter 4.3.7

Platform [ ] All [ ] AntennaTracker [ x ] Copter [ ] Plane [ x ] Rover [ ] Submarine

Airframe type N/A

Hardware type Cube Orange, Cube Orange+, Here3+

Logs N/A

ppastor304 commented 1 year ago

Same problem and same solution with Plane V4.3.7

yuri-rage commented 1 year ago

Further discussion seems to indicate that Here model DroneCAN modules do not function properly at all in moving baseline configurations.

https://discuss.ardupilot.org/t/herepro-moving-baseline-configuration-issues/107156/

yuri-rage commented 1 year ago

Seems I had a bit of a misconception regarding the available feature set on the Here3+. They are not compatible with a moving baseline config, which probably explains some of this.

However, HerePro modules may be similarly afflicted - request this issue be kept open until it can be confirmed that HerePro modules function properly with a moving baseline configuration. At present, it seems they do not.

bugobliterator commented 1 year ago

@yuri-rage I am looking into the issue, you are right trying to set Here3+ as moving baseline will cause issues, most likely they will fail to configure at all. As far as HerePro is concerned, I am looking into the issue.