We’ve added a number of additional safety checks including the two you’ve bumped into.
The “GPS and AHRS differ by 10.9m” is a check to ensure the EKF’s position estimate is within 10m of the GPS position. Are you using wheel encoders by any chance? I’ve only seen this message once myself and it happened when I think I had wheel encoders enabled but carried the rover 10m away. So if this is the issue we may need to ask Paul Riseborough to look into.
The “Flight mode change failed” error is a result of the first I think. The EKF doesn’t have a good position estimate so it’s not allowing the vehicle to be changed into a mode that requires a position estimate.
Did the vehicle appear on the map by any chance after setting the EKF origin? I suspect it did but I’d like to be sure.
The “Flight mode change failed” error must mean that the EKF still doesn’t have a good position estimate. If you can post a dataflash log Paul Riseobough can have a look at it. I worry a bit that the setup is non-standard and that that’s where the issues are… in which case it’s not really fair for Paul to try and work out where the problem is… but in any case, if you have a dataflash log…
I currently do not have any wheel encoders plugged in.
I also get the following errors. In prev versions I did not
[ERROR] [1513135152.385718905]: FCU: GPS positions differ by 93.2m
[ WARN] [1513135152.386053606]: FCU: Flight mode change failed
I had 2 gps systems plugged into the navio2 when I was getting the errors above
(Reach RTK and standard GPS that comes with the Navio).
I have since disabled GPS1 as I would only want to to use the solution from the RTK GPS (GPS2). In this instance I don’t think there is anything for you to solve. I just thought I would put it on here in case people see the same messages while using 2 GPS modules
Thanks for the feedback. We don’t have a lot of beta testers on Rover especially compared to Copter so I’m very happy to hear from you all.
As you probably suspect, the “GSP positions differ by 93.2m” is from our GPS blending and it’s likely a good check 'cuz one of the GPS (probably the one you’ve now disabled) was likely quite far from the vehicle’s actual position.
Happy to help test.
We won’t be able to to do any more test from Friday till early next year as we all go on leave.
I tried the latest nightly build of qgroundcontrol and the joystick still doesn’t seem to work. The warning that the firmware doesn’t support manual control no longer appears, but it shows a warning that the radio isn’t configured and the joystick icon doesn’t appear in the top status bar.
are there any configuration settings in rover I need to change to enable the joystick and disable the rc radio?
Re the joystick not working in QGC, I’ve ping’d Don Gagne on Gitter… maybe he knows why it’s not working…
doing more tests at the moment. It seems that after some time the GPS solution and the AHRS solution will differ to a point where I cannot switch to Guided or Auto mode.
The only way was to restart the ardurover code .
I’ll try upload a log up tonight
Jut out of curiosity . Should I be using EKF3 ?
Does EKF3 produce a more robust AHRS solution ?
We should move rover to use EKF3 and I hope we will do that soon because that will allow easier integration of external position sources (visual odometry, etc) but it should not be a requirement to get a good position estimate.
Yes, a log is a good idea. I suspect that it’s related to the vehicle moving forwards and backwards instead of moving forwards in long straight-ish paths but that’s just a guess. We will probably need @priseborough to help us.
That was exactly what I was doing (moving in a straight line then reverse back to starting position).
Currently, we are testing out some custom ROS code with APM in guided mode.
Nice ! If you had time and permission, could you do a blog post about your work with ardurover and ROS ?
@randy, I got a pr that should reduce influence of the wrong velocity estimation at slow speed.
@derelicte, did you configure the joystick ? I will try today,
@rmackay: thank you!
@khancyr: I have enabled and calibrated the joystick in qgc. one weird thing though is when I have rover loaded on the pixhawk it won’t let me configure the buttons. however when ardusub is loaded I can configure the buttons for auto/man, etc.
I have made some quick test with qgc android beta, I got the virtual joystick and manual control support but not all, configuration phase and reverse thrust button were missing. I don’t think that we support button on rover with virtual joystick
Sorry, Oh Gosh I seem to have stumbled on to another problem. When trying to DL the logs… I get:
Getting list of log files…
Error:System.TimeoutException: Timeout on read - GetLogEntry
at MissionPlanner.MAVLinkInterface.GetLogEntry(UInt16 startno, UInt16 endno) in C:\Users\michael\Source\Repos\MissionPlanner\Mavlink\MAVLinkInterface.cs:line 4565
at MissionPlanner.MAVLinkInterface.GetLogList() in C:\Users\michael\Source\Repos\MissionPlanner\Mavlink\MAVLinkInterface.cs:line 4505
at MissionPlanner.Log.LogDownloadMavLink.b__12_0() in C:\Users\michael\Source\Repos\MissionPlanner\Log\LogDownloadMavLink.cs:line 90
Is this me or ???
I think you need to be disarmed to download logs so perhaps that’s the issue. It’s not a very understandable error message though… that would be an MP thing though.
I finally could setup and config everithing. Runing 3.2.0-rc3
But in manual mode, if I move my sticks, servo output goes from 0 to 500 and is centered on 250
ASV_01.param (11.1 KB)
It sounds kike the mot-type parameter has been set to one-shot. Revert that parameter to 0 and it will probably work. Sorry, i can immediately open the attached param file.
Ok, I reset all parameters to their default values and flash 3.2.0-rc3 (I was playing with dev trunk with no succes).
Then I config all parameters again and now it is working.
Thank for your help! I will start to setup EDISON companion computer and let you know my progress with this beta release.
Great. We have an apsync image for the Edison which might speed up the setup. No pressure of course. http://ardupilot.org/dev/docs/apsync-intro.html