setup as before
AUAV-X2, one “normal” gps+mag on uart and i2c, one uc4h uavcan gps+mag on can, AC3.6-dev of tonight, latest MissonPlanner
this time I only tested for this two configs
GPS_AUTO_CONFIG = 0 or 1
GPS_AUTO_SWITCH = 0
GPS_TYPE = 2
GPS_TPYE2 = 9
I’m not convinced things are working as they should.
First run:
both ublox and uavcan gps connected => things look OK
Second run:
both ublox and uavcan gps connected, but then I disconnected the uavcan gps after startup, and reconnected it a longer while later => this does not look OK to me, eventhough gps2 was disconnected, gps1 gets reconfigured, and strangely enough as UAVCAN at 115200baud, once gps2 became reconnected, things settled correctly
Third run:
first only ublox was connected, after startup uavcan gps was connected => this does not look OK to me, initially gps1 is handled correctly, adding gps2 however also makes gps1 to “reenumerate” again
That’s how GPS enumeration works in AP. It has nothing to do with UAVCAN. Try different types of GPSs apart from UAVCAN and you will get the same results.
I am however concerned with test 2 and will try to figure out why that misnaming happens.
well, this might be in fact correct, and that what I describe isn’t related to having a uavcan gps
that was indeed an implied assumption of mine which might be a fallacy
but
this doesn’t make it any better.
I still would not call it proper behavior. I think that if gps2 is removed it should not lead to gps1 disappearing and running into an infinite loop of trys to enumerate gps1 correctly …
also: Being frightened to death (;)) I clearly have not attempted a flight, so I don’t know what would happen then. I would be very thankful if I could get a statement as regards what would happen during flight if one gps disappears … it also would make both gpses go and one gps to re-enumerate for indefinite? (can be answered with a plain yes or no)
@EShamaev The primary problem is copying the GPS state structure which has been null initilized in the UAVCAN backend is invalid. You need to at least update the state.instance variable. (Or better yet we ditch state.instance, and just make it a member variable of GPS_Backend).
@WickedShell Or better yet, the UAVCAN backend just copies the variables of the structure that it receives. Copying the entire structure isn’t a good behaviour.
@OXINARF: Agreed this is actually a large problem as the assumption in the GPS frontend is that it can use fields in GPS state freely, and that backends only fill in what they need. This can be reworked to not be the case, and we can make it a firm requirement for the future, but at the moment it is a real problem. I spent ~10 minutes perusing this when I noticed it after Olli’s report and it appears at the moment instance is the only one that is incorrect, but there could be something else lurking there.
To me it looks that first the logic should be worked out and/or specified, and then put into code.