ArduRover on real competition R/C 1/10 car on real circuit: missions. FAR FROM WORKING

which is reached frequently as seen on RCOU.C2.

I’ll increase this. However, with CRUISE_SPEED=4.7 and not having inserted DO_CHANGE_SPEED waypoints, the car simply goes too fast (in another test, also at 4.7m/s, the car was stopped at a barrier), as well as at 1.6m/s the car went too fast at the small circuit.


Minimum RCOU.C2 is seen as SERVO2_TRIM: the car does not brake. Above (december 18):
“… On the big circuit add DO_CHANGE_SPEED waypoints and improve lap time. How can I brake the car?…”
No answer.

These are the waypoints types:
I wonder if a DO_CHANGE_SPEED with a negative speed would make the car brake, making R2.COU go under SERVO2_TRIM=1517.

…What is your hardware setup with regard to accelerometers and connected wires? Do you indeed have two sets? Is one of them subject to more electromagnetic interference than the other?..

The controller is a Pixhawk, with the adition of two external compasses. The probable sensors are as follows:

From the Pixhawk documentation:
-MPU6000 as main accel and gyro
-ST Micro 16-bit gyroscope
-ST Micro 14-bit accelerometer/compass (magnetometer)
-MEAS barometer

The MPU6000 and the MEAS barometer are clear in the schematic above (MPU-6000 (from Invensense) and MS5611 (from TE)), but not so much the ST components.

From ST documentation:
L3GD20H: 3-axis gyroscope, I2C/SPI digital output, low-power 3-axis angular rate sensor, 16 bit rate value data output, I2C/SPI digital output interface.
LSM303D: 3D accelerometer and 3D magnetometer, 16-bit data output, I2C serial interface

So the ST Micro 16-bit gyroscope in the Pixhawk documentation should be the L3GD20H in the schematic, and the ST Micro 14-bit accelerometer/compass (magnetometer) could be the LSM303D in the schematic, being “14.bit” an error.

What is labelled X503 (offboard gyro/accel/mag), being others labelled Uxxx, should be an SPI gyro/accel/mag (I don’t know which), but I have not added anything like this.

So IMU1 and IMU2 are those inside the Pixhawk, moreless in the same conditions (at different distances from the 3DR antenna or the motor). Being from different manufacturers (Invensense and TE) they may behave differently.

Is there a setting to make it ignore IMU2 and look at IMU1 only?

EK2_IMU_MASK = 10000000b instead of EK2_IMU_MASK=11000000b. (i.e. 1 instead of 3). I think that should disable IMU2.

There is also INS_USE2 = 0. I’m not sure the difference between this and EK2_IMU_MASK and EK3_IMU_MASK.


Also I still think your waypoint radius WP_RADIUS is too large. Right now it is 1 m, so several zones around waypoints overlap. This would be especially bad on the 1/18 course. I recommend trying 0.1 m or 0.2 m if possible.

Same thing for WP_OVERSHOOT. Right now you have it 1 m. Together with tightening WP_RADIUS I would tighten WP_OVERSHOOT to 0.1 m or 0.2 m and see what happens.

In 20190211_RTK2_Asoger_92.bin, I do not see the commanded servo position clipping at 1517 µs pulsewidth. I can’t rule out the flight controller simply calculating decelerations less aggressive than you are expecting, rather than an inability to command servo positions below 1517. Do you have another data set where it more clearly clips at 1517?

Instead, I notice ATC_ACCEL_MAX is only 0.2 m/s². Next, ATC_DECEL_MAX is set to 0, which I think forces parameter ATC_ACCEL_MAX to specify both the acceleration and deceleration maximums. From the Rover parameter list definitions:

ATC_DECEL_MAX: Speed control deceleration maximum in m/s/s

Speed control and deceleration maximum in m/s/s. 0 to use ATC_ACCEL_MAX for deceleration

I would try either increasing ATC_ACCEL_MAX to something more aggressive yet still short of nonlinear effects like wheelspin and lockup, say 5 m/s² or 10 m/s² or else increasing (decreasing?) ATC_DECEL_MAX to something other than 0.

Having said that, I see THR.AccY often exceeds ±2m/s². I am missing something.

@rmackay9: what is the definition of THR.AccY? Is it commanded or measured acceleration? What would make it exceed ATC_ACCEL_MAX?

“… Minimum RCOU.C2 is seen as SERVO2_TRIM : the car does not brake …”

This is true, but the real situation is worse. Filtering the MAVLink messages for only RCOU, exporting values, selecting C2 values only, and selecting range from the first 1600 till the last 1600 (exclude longly mission start and end), the minimum value is 1525, so really it is always above SERVO2_TRIM.


From documentation:
ATC_ACCEL_MAX: Speed control acceleration (and deceleration) maximum in m/s/s
Speed control acceleration (and deceleration) maximum in m/s/s. 0 to disable acceleration limiting
ATC_BRAKE: Speed control brake enable/disable
Speed control brake enable/disable. Allows sending a reversed output to the motors to slow the vehicle.
ATC_DECEL_MAX: Speed control deceleration maximum in m/s/s
Speed control and deceleration maximum in m/s/s. 0 to use ATC_ACCEL_MAX for deceleration.

I’ll change ATC_ACCEL_MAX to 0 mantaining ATC_DECEL_MAX at 0 (no acceleration and deceleration limit) and see what happens.

Although this cars don’t use reverse speed when racing (not allowed), it can be programmed on some brushless ESC’s to get rid of an obstacle, reversing speed. I think it is done braking, releasing and braking again: the car then goes backwards.

It may be more or less clear in the video, but with this set of waypoints the car decelerates in the middle or in the end of the curves (it was clear observing the car doing the mission). Possibly this happens by sensing lateral acceleration. In this sense, now it behaves like a bad driver (it could anticipate braking with angle between current trajectory and line formed by next two waypoints).

So for next test:
SERVO2_MAX 1700 (or so)

I think the solution to the problem in John Easton’s path wobble thread would work here too. That is, until the software is fixed, consider putting the throttle back on R/C control and having the autopilot control steering only.

Yes throttle is the main contributor to the path wobble.

Here are other 4K videos with simultaneous GPS ArduRover-Arducopter missions, filmed with camera on tripod.

Rover-5 – QuadX-7

Rover-5 – QuadX-3 – QuadX-7

Both drones have led lights at the back. The circuit main straights are north-south, and the mission has a ROI at a far point at the west, so the drones can be followed easily even being far (leds point east, moreless towards the camera).

This video (three MP instances, three 3DR radio pairs) includes the three tlogs captures:
intro 0" - 20"
tlogs 20" - 7’50"
video 7.50" - end

Must be improved:
-Drones height loss: QuadX-3 touches ground at the middle of the far straight

-3DR links data loss.

There can be accidents in these GPS simultaneous missions:

This is a new 4K video of rover on a GPS mission followed by drones.

Recorded with camera on tripod.

-Rover followed by three drones.
-Wifi communication (with router). No reception errors, as can be checked on the tlog capture (after second 20). Connection to RTK station for the RTK GPS’s in the rover is done by the router.
-4 MP instances on laptop for the three drones and the rover, using the three Windows 10 spanish voices as follows:
*QuadX-1: Helena.
*QuadX-3: Pablo.
*QuadX-7: Laura.
*Rover-5: Pablo.
-{sysid} on MP spoken messages, to distinguish vehicle.
-Added current (magnetic) and voltage (resistive divider) on rover.
-Previous rover external compasses (HMC5883 and HMC5983) disconnected; used instead LIS3MDL on one of the RTK GPS’s.
-Compasses calibration done without motor.

Mission ROI on west, so that the three drones show their leds to the camera all the time.

First, rover is armed (Arm/Disarm button on its MP instance on laptop). Then drones are started manually: arm, lift, mission start and brake. Then rover is put on AUTO (AUTO button on its MP instance on laptop) and the three drones are liberated one after the other.

Before rover arming, message “Compasses inconsistent” was heard at times. Simply moving the car a few centimeters (changing rotor position) seemed to solve this (beep heard).

Rover is positioned opposite to mission start, but at mission start (AUTO button) it immediately turns (seems to read compass).

When QuadX-7 started the third lap, it landed. One of its battery elements failed completely (0V).

RTK FIXED on both RTK GPS’s during some instants:

Rover lap-to-lap repeatability looks good. Course following is still nowhere near as good as the quadcopters.

What’s next?

Although rover gets RTK FIXED during some instants, it is now a mystery why RTK works better on some days (probably a better satellites arrangement, but I don’t know how to predict it).

For example, compare:


The second video shows that the GPS’s separation is detected, and the separation calculated from the coordinates difference is the same as the physical separation (0.0000005º -> 10000000000*0.0000005/90 = 55.55mm <> 52mm). Why that was such a good RTK day is a mystery.

Yes, the quadcopters seem to follow the waypoints better and have smaller turning radius. The rover, at constant speed, seemed to go too fast, and constantly approaches circuits limits (in fact, I had to reduce its speed from 4 (speed used previously) to 3m/s). Observe that on the second and third pass at the curve after the podium it reaches limits, but not on the first pass after starting. So I’ll have to try speed change waypoints.

In the past, I observed that the rover ran slightly slower. Here I used 2.95m/s for the quadcopters, but the rover is clearly faster, even going to the track limits, apparently with longer trayectory.

After being sure about the “RTK good days”, I have two sonars prepared to try obstacle detection at right and left (metallic guides outside from the track).

I think it would be at least entertaining and probably enlightening to drive the rover with autopilot controlling the steering but you manually controlling the throttle and braking with normal R/C.

Imagine a RC car with two receivers, one attached to steering and the other to accelerator/brake, with two drivers trying to control it: coordination impossible.

·The HDOP and other parameters can be predicted.
·Rover beta Rover-4.0.0-rc1. I’ll try next week if HDOP predicted under 0.5.

The minute you go over 3m/s the 2.1 black cube freaks out for some or other reason.

These are similar trajectories and videos (4K), but with rover firmware 4.0.0-rc1.

Rover trajectories (outer) are tighter than in previous version. This gives room to increase speed (still fixed), perhaps to 3.5m/s, and so shorten mission duration (battery duration is critical for two of the drones, as can be seen).

All this was on a good RTK GPS day:

1 Like

We have been working on getting a rover to follow a precise course in a similar fashion to you - with varying degrees of success. After looking through the code, it is apparent that while the linear velocity is controlled to allow ‘Turn radius’ cornering within the set ‘Turn G Max’, the L1 controller never commands such turns. The actual lateral accelerations out of the L1 controller never even consider the intentional deviation between successive way points but simply continues to attempt to reduce the suddenly large error. The point ahead on the path that the L1 controller attempts to achieve is determined in part, by the current speed. By reducing the speed of the vehicle you can move this point closer to the current position and get tighter turns. In planning way points, we have found that if we insert ‘DO_CHANGE_SPEED’ commands to reduce the speed before a corner and again after to return the vehicle speed to normal cruise speed, we can achieve much tighter turns. Adding these speed changes to the plan can be a bit painful so we have a script for that. We have also been working on some changes to the code that handles the cornering independent of the L1 controller so that we can achieve what we want without adding all the additional points as well as be more flexible with the speed.


There should be a better solution then DO_CHANGE_SPEED commands. I have it pending to test, but to improve lap times. Of course, better cornering in code would be ideal.

-Drones (with conventional GPS’s) follow waypoints better, although the rover (RTK GPS) repeats better.
-Rover fit to waypoints has improved in version 4 (slight speed increase without hitting barriers).

For possible precision with the RTK GPS’s used, see this.