Can't get basic Rover functionality with recent code (v1.8.0)

Hi all,

I am having difficulty running the rover airframe in Gazebo. I’m using Gazebo 9 and QGroundCOntrol v3.3.2, and have recently (26 Jun 2018) synched my github fork with the PX4 master. I have made only a small change to posix-configs/SITL/init/ekf2/rover to allow QGroundControl to run on a Windows PC, while Gazebo and the autopilot run on a different machine running Ubuntu 16.04. Otherwise, I am running PX4 “out of the box” as it existed on the master branch two days ago. I believe that is roughly equivalent to v1.8.0.

I set up a small three-waypoint mission in a triangle with the last waypoint on top of the home position. The mission consists of the “Mission Start” box, where the vehicle fills in the altitude at 9.1 m. “Flight Speed” is set to 5 m/s, but I leave the box unchecked. “Return to Launch” is unchecked. All waypoints are set to altitude 0 relative to home.

When I start the mission, the rover heads toward the first waypoint. If Ground Speed doesn’t get above about 5 m/s, it will operate successfully, but if it gets going too fast, the rover seems to start flying. Altitude can show about 2 meters in QGC. When this happens, the autopilot complains about the GPS and enters a failsafe mode. In Gazebo, it stops. In QGC, it begins wandering around aimlessly (usually, but I have seen it once make a bee-line towards a position in the ocean off the west coast of Africa). I have to disarm it from the command line as shown below.

pxh> commander mode auto:mission
pxh> commander arm
pxh> commander disarmWARN [commander_tests] Failsafe enabled: no global position
WARN [navigator] Global position failure: fixed bank loiter

pxh> INFO [sdlog2] [blackbox] stopped (358395 drops)
WARN [sdlog2] extended logging: OFF
WARN [sdlog2] time: gps: 0 seconds
WARN [sdlog2] not logging
WARN [ecl/EKF] EKF GPS fusion timeout - reset to GPS
WARN [ecl/EKF] EKF GPS fusion timeout - reset to GPS
WARN [ecl/EKF] EKF invalid accel bias - resetting covariance

I can force it to navigate the three waypoints by making it slow down. I’m sure there are other ways to do this, but I did it by setting GND_SPEED_MAX to 0.2. By the way, I do not believe that this parameter is actually in m/s. The value is handed directly to the PID controller as “output_limit”. I’m guessing that the value should actually be between 0.0 and 1.0.

Even using this kluge, I have to disarm it as soon as it reaches waypoint 3, because it doesn’t know what to do after that, and I’m not supposed to use an RTL (and it doesn’t work anyway).

At this point, I have some basic questions. Should I even expect the rover to work when using v1.8.0? Has anybody run this successfully using the current master branch?

I have seen the video at Redirecting to latest version of document (master), so I can see that it was working quite well at some point, both in simulation and on real hardware. But the initial code was pushed over a year ago, so I suspect that video is at least a year old.

Another issue we’ve been having is that the Rover airframe configurations have at times disappeared from the airframes.xml file, as packaged in the px4fmu-v3_default.px4. So the person here who is working with a physical rover has no way to configure it as a rover – downloading a PixHawk 2.1 through QGC erases all knowledge of the Rover in QGC. To get around this, I had been giving him custom versions of airframes.md and airframes.xml to manually put into QGC’s \users<foo>\AppData\Roaming\QGroundControl.org folder in Windows, but as of v1.8.0, the rover showed back up. Problem is, the file that is appears in Windows’ QGC file system, PX4AirframeFactMetaData.xml, contains only one line for all rovers:
< airframe_group image=“Rover” name=“Rover” />
… which doesn’t seem to be enough. The Rover picture shows up in QGC, but he cannot get any motors to operate.

If I build airframes.xml myself using
make airframe_metadata
the old Rover configuration is back, which consists of additional information for three Rovers. I don’t know yet if manually introducing these files into QGC will help him get any further. And I suppose he may need the files produced by this:
make parameters_metadata
as well. Is that true?

Another thing. I tried to git checkout v1.7.0 and build the system as it used to exist, but the PX4 Gazebo target won’t build. There are numerous C++ header files missing. I am guessing that this release works only with Gazebo 8. Is that true?

I’d be grateful if somebody could try to build and run a rover traxxis from the current master branch using Gazebo 9, and report whether or not you can get it to work. It looks badly broken to me, but I could very well be doing something wrong.

Any other suggestions are also welcome.

Also, there are a few plot sets available if anybody wants to take a look. This is from several days ago. I don’t remember exactly how the mission was configured, but it only consisted of altitude-zero waypoints and the mission start box as previously described. I’ll also mention that I was, in desperation, running with a nightly build of QGC at the time. I have since reverted to v3.3.2.

http://logs.uaventure.com/view/vZX8jeghn2y2iCf3XXEMRe
http://logs.uaventure.com/view/NxCGNNJ7xAZjo9Xe4BLr7F

Thanks for any and all suggestions!

Vic

Don’t know if anybody has noticed my question, but here is some followup. What’s happening is that the horizontal position innovations are diverging in the EKF, and the covariance becomes too large, so the EKF invalidates the GPS data, upon which commander tells the rover to land. The simulated GPS data looks fine as far as I can tell. Unfortunately, I am not a Kalman Filter expert, so I have been unable to make further progress. I have attached 17_57_42.ulg.pdf from a simulated run made on July 2, 2018. The corresponding on-line analysis can be found here: Flight Review

If anybody has an idea how to proceed, that would be much appreciated.

17_57_42.ulg.pdf (163.2 KB)

Thanks,

Vic

@Paul_Riseborough

17_57_42.ulg can be found here: http://sperry.homeip.net://17_57_42.ulg

You need to fix the IMU accel data:

Thanks, Paul! I will take a look.