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

With respect to the observed barometer overpressure glitches, these are BARO.Alt and RFND.Dist1 on missions consisting in three consecutive takeoff and landing:


which correspond to these 4K videos:

What can be done about these glitches?

BTW1, drone central body had been surrounded with american tape (which was not supposed to have any effect (same glitches)), as appears in this other video:

BTW2, in this last video flight there were several minutes with RTK fixed (GPS2.Status=6):

The GPS RTK led can be seen constantly on in that video.

The test was near the R/C car circuit above but with open sky (although on a cloudy and rainy day), 14.75 Km from the RTK station. The R/C car circuit is surrounded by tall trees, so its conditions are worse.


Jakob Schmidt

If you click on the EKF symbol, it’ll pop up a small window, showing you which parts it’s struggling (GPS, compass, AHRS, etc).

EKF_Status_Terrain

Doing so, on a drone flight I captured above, but I cannot interpret it.

On the log appears:
ERR, 522890012, 24, 0
MSG, 522890048, EKF primary changed:0

How can I guess the error cause?

Ehh, not sure! Terrain following enabled, but no terrain loaded?

Thanks. Inadvertently I had TERRAIN_ENABLE=1, not using that feature at all.

Drone landing with RTK GPS repeatability test.

On drone with RTK GPS and:
ChibiOS: ff603d11
ArduCopter V3.6.0-rc12 (014022de)
from this video with repetitive landings:


giving this GPS Status:

(RTK float/RTK fixed)
these are captures of landings on the two nearest to the camera landing points:

Close, but not at the centimeter level.

After waiting long for a new version, I tried it:
MSG, 48043525, ArduRover V3.5.0-rc1 (f53c86f5)
MSG, 48043555, ChibiOS: 57801550
MSG, 48043605, fmuv2 00320046 35365118 37353630
on the car, with same three laps mission on same real R/C car circuit, and same Drotek XL RTK GPS (only one GPS).

Things went very smoothly, as with the drone above on october 11. Here are three 4K videos:

(CRUISE_SPEED 3m/s)

(CRUISE_SPEED 3m/s)

(CRUISE_SPEED 4.5m/s)


Being a bit dark, the GPS RTK red led can be seen flashing (RTK float).

After a first fast mission test, I aborted it and prepared for recording, but I couldn’t restart the mission even with a Mission Planner soft restart (PREFLIGHT_REBOOT_SHUT). Finally I switched the car off and on.

Also, the µSD card being used gave “Bad logging”, as well as other one, showing no logs on card (even being there). Finally, I used Mission Planner button “Delete logs” and for some reason could log (even old logs appeared). So only third video has a log which is this:
20181119_RTK_Asoger_3.bin

Possibly, the main difference for future tests is the confidence in that the car wont’k knock barriers.

Trajectories:

On the three videos the car is started facing south, and smoothly changes to north, towards first waypoint.

Possibly, increasing speed from 3 (first two videos) to 4.5m/s makes trajectories depart a bit.

Things went smooth even appearing same warnings about the compass.

Great work!

2 Likes

This test was on a 2m wide circuit beside that mentioned above meant for 1/18 cars.

Rover_20181127_RTK_Asoger18_6_waypoints

Nice! This has been one of my favourite blogs here. Glad to see it coming together!

Initial tests on the 2m wide circuit (changing speed):

An 1/8 R/C bike pursuing the car (with a 10 laps mission programmed):

Needs improvement.

On the 1/18 scale course why is it missing waypoints 5 and 6 so badly? Would it help to reduce the waypoint radius?

The main problem is that it is not yet repetitive on the 2m wide track. See that the first trials (20181125) were on a rainy day, but were successful. I tried on a sunny day with no clouds at all and couldn’t get a single lap.

The 2m wide track is on a corner, surrounded by trees, perhaps with less satellites.

Is it possible to rely more on inertial navigation and less on GPS? I thought I saw a setting for that.

I see these to weight the compass (magnetometer) versus the GPS units:

EK2_MAG_M_NSE
EK3_VELNE_M_NSE
EK3_POSNE_M_NSE

Does the navigation not use the gyro and accelerometers to calculate an inertially-derived position and velocity? For a car driving close by ferromagnetic objects and executing rapid maneuvers with high yaw rate in a geographically small course, it seems this would be preferred.

I’m envisioning the inertial navigation would guide the car on the 10 µs to 10 s range, and the GPS would correct the position much more slowly (less often), like 10 s to 100 s. Does the code support this approach?

I have a lot of respect for the OP for fighting through this for many months. Especially given that the quadcopter with the same hardware works so well, this must be extremely frustrating.

1 Like

Earlier you mentioned the throttle is limited to a low value for safety during testing. How often does the commanded throttle reach this limit?

I would think this clipping behavior would cause a severe nonlinearity that could possibly be faking out the control algorithm. If it is hitting the throttle limit often, consider relaxing (i.e. raising somewhat) the limit and see if that helps the behavior.

Indeed, testing in the big circuit, with CRUISE_SPEED up to 4.5 m/s RCOU.C2 reaches SERVO2_MAX=1600, so it is clipped. But speed regulation is not important now, and the results on the big circuit with RTK are reasonable, although just in one last test. The point now is to follow the desired trajectory reliably with RTK. The car hits the barriers constantly in these tests, so it is not convenient to reduce SERVO2_MAX.

So I started tests on the 2m wide circuit, and the results are not consistent. And because of the ChiBios problems with µSD cards I have not got yet long logs.

This is an example of RCOU.C2 on the 2m wide circuit. With CRUISE_SPEED 1.1 m/s it is rarely clipped, although the log is short:


RCOU.C2 has a minimum of 1517, which corresponds to SERVO2_TRIM. I have not tried yet to insert DO_CHANGE_SPEED waypoints, and have no idea if the car can brake. I haven’t tried either DO_SET_REVERSE waypoints, meant to drive in reverse. These type of competition cars don’t have reverse, so if this implies pulse under SERVO2_TRIM the car would brake.

Perhaps Randy can clarify braking.

I think that proves throttle clipping is not a problem. On a side note, the output seems to be demanding high acceleration and jerk in a few spots (around sample 90000 for example), which by itself is perhaps a symptom of the problem.

I still think reducing the waypoint radius would help behavior on the 1/18 track. The current diameter of each circle is the entire width of the track, allowing close approach to the barriers to be a valid solution. Some of the circles even overlap, which I think would validate vague paths.

I encourage reducing the waypoint radius to 0.2 m and trying again on the small track.

1 Like

Can you post your most recent log? I’m interested in helping.

Here is a long log of a 10x32 mission (10 laps) in the 2m wide circuit:
Rover_20181214_RTK_Asoger18_12.bin (100 MB)

There are two runs, whose videos are:


On the first video, initially the car had to be constantly put in place; this improved for whatever the reason, and recording was started, so not all waypoints appear. The second is moreless complete (the mobile phone used has a 10’ video limit, so recording has to be restarted, losing some seconds, and later joining videos.

The tlog’s are included in both videos.

The red flashing led on the GPS on top of the car indicates “rtk float” (steady on indicates “rtk fixed”).

As seen, the laps are irregular: bad laps, with car knocking the barriers and even being stopped, car completely out of trajectory, and good laps indicating that coordinates used are moreless correct (perhaps waypoints 8+32n can be shifted 1m south).

POS+waypoints:

On the average, perhaps the number of detected satellites increased from the first run to the second:

With respect to the irregular waypoints linkage, it can be related to this:

First, I think you should pay attention to the following thread: John Easton's battle with 'Wobbly Path' - [NOT SOLVED]

Second, I notice that you have some P-oscillations in steering. Decrease ATC_STR_RAT_P by 50%. Your actual steering rate is matching your desired turning rate, so that is good (FF-gain is set very close to correct).

Your TURN_MAX_G is set to 0.3, and I think this is far too low (causing your car to try to turn at all times rather than hit the navigation lines and stay on them). You need to get your car to hit its desired heading on the line VERY quickly so that you have precise control of the navigation. Then from there you can “soften” things up. Right now your navigation is “sloppy,” and I think in part it is due to TURN_MAX_G and maybe NAVL1_PERIOD. Your navigation is so “quick” that I think NAVL1_PERIOD may need to be <5.

Thanks a lot for the link and your comments about parameter adjustments, not only valuable for car behaviour improvements, but also for understanding their meaning towards a better knowledge of all this. I will test these changes shortly.

In fact, the steering oscillations are clearly seen on some instants on the videos, and I had occasionally seen them also in the big circuit.

However, I’d like to know how to make the car behave always the same, good or bad, but the same. There are good laps and bad laps, and the second run is better on the average. There are more satellites on the average on the second run, and the tlog part of the videos (starting on both at 20") clearly show the good and the bad laps.

The 2m wide R/C car circuit is on a corner, surrounded by tall trees.

HDop is on the average better on the second run:

Observe carefully instants following t=165 on the second run:

While in a good lap, the car suddenly loses trajectory and then recovers. Down and left in the video are shown HDop and Sats, which increase and decrease briefly respectively and then recover. This is a capture once recovered:


(Captured after recovery)

The car is using three compasses (the one on the RTK GPS is not connected):
-Two external at the front bumper, away from the motor.
-The Pixhawk internal one (perhaps should be disabled).

The GPS is above a copper plane, now floating. Perhaps it should be grounded, and the GPS ground connected directly to it.

Would it be convenient or possible to filter the GPS or compass data to avoid sudden trajectory changes?

BTW, this is the version used:
ArduRover V3.5.0-rc1 (f53c86f5)
PX4: bcbd027a NuttX: 1472b16c
PX4v2 00320046 35365118 37353630

With NuttX, no µSD card logging problems.