Randy, that lane based stuff looks very interesting. Have you confirmed what’s making it take such a wide path at higher speed before you implement the speed decrease? Is it actually hitting the turn_max_g?
I’m finding that 3.4 in sim is behaving differently than 3.3 - it seems to be turning much wider and limits the applied steering well before it hits turn_max_g.
Are you able to post that demo waypoint file and param file, and any changes to the SIM_Rover model?
I don’t fully understand the L1 controller yet (although I’ve documented what I know here on the wiki) but it seems that if the vehicle goes faster, it ends up taking wider turns so at the moment, the key to tight turns is just going slower. The current method in master for slowing down at turns scales down the speed which means that if the WP_SPEED is set higher, the vehicle will definitely make wider turns (assuming no other parameters are touched). The new method limits the speed to ensure the vehicle doesn’t turn too wide. Maybe this was clear already but just to be sure…
Here’s a link to the waypoints file.
I’m not sure why 3.4 would make wider turns than 3.3. All that comes to mind is that we’ve got the acceleration/deceleration limiting working well now. We’ve also changed some defaults including reducing the TURN_MAX_G default… but I’m guessing, I’ll try and investigate…
Thanks. Is that run with otherwise default beta r3.4 parameters and the standard SIM_Rover model?
I’ll run it in 3.4 and 3.3 and see how it looks.
@rmackay9, I can’t show what I was hoping specifically there. It must have been some funky combination of parameters.
I’ve found something interesting re 3.4 - I’ll post over there.
Here is a mission file:
Rover_20180606_203.BIN.txt (11.2 KB)
which should be:
(6x4 waypoints following a rectangle 6 times, with WP_RADIUS=1)
Here is a link to the log (20MB):
Rover_20180606_203.log: https://mega.nz/#!nUJAgSRa!Op_ocYv7WLlHfvJXQZP5-5WhTc99Lf_jj07A30uJOP0
and the resulting kmz (as zip):
Rover_20180606_203.kmz.zip (294.7 KB)
As seen, they don’t follow at all the rectangle.
The steering wheels oscillated all the time.
Here is the param file:
Rover_20180606_203.BIN.txt (11.2 KB)
BTW, when in Mission Planner->Dataflash logs->button “Auto Analysis”, I always get this error:
BTW2, this is the mission to follow on the nearby real RC car circuit:
asoger_alt0.txt (3.0 KB)
I changed to Rover version 3.4 beta:
PX4v2 004B0036 3436510A 32393637
PX4: b535f974 NuttX: 1472b16c
ArduRover V3.4.0-rc1 (615d7afc)
and tried a three laps mission:
It was generated copying and pasting: waypoints 1-33 and 34-66 are 67-99. 100 is a finishing point. References below are to points 67 to 99. This is the final version, after some position trimming on some waypoints. This permits to analyze lap to lap trajectory repeatability.
Overall performance was better. Here are two videos, with 2.2m/s speed:
This are links to two of several logs obtained:
Rover_201806114_217.bin
Rover_201806114_220.bin
On first one, on one lap there are great deviations around points 82 to 86.
On second one the car hits a a circuit barrier between points 70 to 71 (rangefinders adjustment pending), which should appear on accelerometers.
Here are some captures from kmz files (POS messages):
The irregularities at the beginning are simply due to initial car positioning at the asphalt.
Although the overall result is good, this happened:
-As predicted above, and even being the speed so low (2.2m/s), turns widen. Passing barrier between points 70 to 71 was difficult, even trimming waypoints.
-Partial repeatability.
-Occasionally steering oscillates, specially approaching some waypoints.
I’ll try procedures suggested in:
http://ardupilot.org/rover/docs/rover-tuning-navigation.html
Finally, I increased speed from 2.2m/s to 2.7m/s. It was impossible to complete the mission. Here is a video showing how the car stops at barrier between waypoints 70 to 71 after starting second lap:
Here is a link to the log:
Rover_201806114_224.bin
and this is the trajectory (POS):
Webillo,
Thanks for the log and video! It’s really great to see videos of these vehicles in action.
I think the wide turns are because the steering turn rate controller is not very well tuned. If we have a look at the Desired vs Actual Turn rate graph below there are clearly two problems:
Could you try these new parameter values and see how it does? Thanks!
Thanks for the suggestions.
I have tried this mission:
(BTW, are WP_OVERSHOOT and WP_RADIUS important?)
This was a first log:
Rover_20180617_225.bin
that produced this trajectory:
The car was left on the asphalt, went to waypoint 1, continued mission, but turn at waypoint 8 widened and the car crashed. So for next test there I will shift right 1m the points at the left, although it seems that now turns are sharper.
Observing DesturnRate and TurnRate:
This was another log:
Rover_20180617_226.bin
Capturing from the kmz file:
The car did not follow at all the trajectory, went out of control and hit an obstacle, as had happened days ago (image with green vertical bars above). This happened twice.
DesturnRate has no sense:
Above, on Mission Planner->Dataflash logs->button “Auto Analysis” appeared an error.
Now I tried Mission Planner on an administrative acount and got this:
So it seems that Mission Planner must be debugged checking permissions. In the meanwhile, execute Mission Planner as Administrator.
As appears above:
Test: Compass = FAIL - Large change in mag-field (157.21%)Max mag field length (611.18) > recommended (550.00)
and repeating the analysis on previous logs (big circuit):
Rover_201806114_217.bin:
Test: Compass = FAIL - Large change in mag-field (149.57%)Max mag field length (575.86) > recommended (550.00)
Rover_201806114_220.bin:
Test: Compass = FAIL - Large change in mag-field (178.86%)Max mag field length (699.61) > recommended (550.00)
Rover_201806114_224.bin:
Test: Compass = FAIL - Large change in mag-field (215.38%)Max mag field length (627.98) > recommended (550.00)
There is a big magnetic container under the trees at the right, so the car is going to pass beside it on each lap on this mission, and also on missions on the big circuit. There may be other big metallic objects nearby, which can be magnetized, such as the podium. Note that this is a real circuit, and cannot be changed.
For the rectangle mission here (almost two rectangle laps), here are MagX, MagY and MagZ:
Questions:
-Is this important?
-Could this explain the crashes?
-Does the program do any filtering, such as detect a big magnetic disturbance and reject compass data (rely on GPS)?
I’ve created an issue for MP for the security issue (anybody can raise these issues by the way).
Regarding driving off, I agree that the compass/heading is likely the cause. It is probably a good idea to disable the internal compass (set COMPASS_USE2 = 0).
We can see from the logs that the vehicle knows it’s getting further and further from the track. I think we need to add a failsafe to change the vehicle into HOLD mode if we sense the vehicle is driving off.
MAG (red) is the external compass, placed at the front bumper, as far as possible from the motor.
MAG2 (green) is the internal compass (disabled).
After some tuning, with these parameters:
ATC_STR_RAT_D 0
ATC_STR_RAT_FF 0.7
ATC_STR_RAT_P 0.5
ATC_STR_RAT_I 0.6
CRUISE_SPEED 2.4 (still very low)
WP_SPEED 0
and having yet to try this:
Steering Turn Rate Control tuning video
I tried this mission:
This is the log:
Rover_20180619_234.bin
This is fit between DesTurnRate and TurnRate:
This is the video
and this is the result:
Seems satisfactory, but trying on the big circuit this was the result:
Although the car passed better the barrier between waypoints 70 and 71 mentioned above, the car deviated at other points and went off circuit or knocked slightly some barriers.
How can the fit to the GPS waypoints be improved?
BTW2, what is the importance of:
WP_OVERSHOOT 1
WP_RADIUS 1
parameters?
OK, so it looks like the vehicle is using Rover-3.4.0. Could you try Rover-3.4.1-rc1? This includes the lane based speed control and also fixes an issue with the steering output being limited. The lane based speed control really was built for this kind of situation so I hope it will help.
WP_OVERSHOOT is suppose to be used to reduce the speed of the car so that it stays on the line between waypoints. In 3.4.0 it is used to calculate how fast it can be going before reaching a waypoint so that it doesn’t overshoot too much. In 3.4.1 it is also used to slow the vehicle if it gets too far off the track. You can easily see how far the car is from the line between waypoints by graphing NTUN.XT.
WP_RADIUS controls when the navigation code thinks it has reached a waypoint. So if WP_RADIUS = 1, once the car is within 1m of the waypoint, it thinks it is complete and will start towards the next waypoint.
I programmed V3.4.1-rc1:
PX4v2 004B0036 3436510A 32393637
PX4: b535f974 NuttX: 1472b16c
ArduRover V3.4.1-rc1 (3ee064da)
(BTW, programming firmware in Mission Planner is a mess, even with “Force PX4 Bootloader”.
QGroundControl is immediate:
QGroundControl can upgrade the firmware on Pixhawk devices, SiK Radios and PX4 Flow Smart Cameras.
All QGroundControl connections to vehicles must be disconnected prior to firmware upgrade.
Please unplug your Pixhawk and/or Radio from USB.
Plug in your device via USB to start firmware upgrade.
Found device: PX4 FMU V2
Connected to bootloader:
Version: 4
Board ID: 9
Flash size: 2080768
Downloading firmware…
From: http://firmware.ardupilot.org/Rover/beta/PX4/APMrover2-v2.px4
Download complete
MAV_AUTOPILOT = 12
Successfully decompressed parameter_xml
Successfully decompressed airframe_xml
Successfully decompressed image
Erasing previous program…
Erase complete
Programming new version…
Program complete
Verifying program…
Verify complete
Upgrade complete)
After some adjustments this was the last log:
Rover_20180624_237.BIN
with:
ACRO_TURN_RATE 180
ATC_STR_RAT_I 0.6
ATC_STR_RAT_P 0.5
ATC_STR_RAT_FF 1.1
CRUISE_SPEED 2.4
WP_OVERSHOOT 1
WP_RADIUS 1
WP_SPEED 0
Three eights:
Big circuit:
TurnRate vs DesTurnRate:
NTUN.XT:
Trajectory follows waypoints better. At specific waypoints (80, 82, 84, 88) it departs, for whatever the reason.
I’ll try to increase speed and use DO_CHANGE_SPEED.
Webillo,
Just had a quick look at the logs and it’s looking pretty good!
It might be good to turn off object avoidance by setting RNGFND_TYPE = 0.
The 2nd GPS doesn’t appear to be working very well so I think disabling it would be good (set GPS_TYPE2 = 0). We can see it is not working well by clicking “show map” when viewing the dataflash log. the green line is very far off from the others.
To make the vehicle slow down more it might be interesting to try reducing TURN_MAX_G from 0.6 to a lower number like 0.4 or 0.3.
The performance in the Auto mission near the end of the logs looks pretty good. The desired turn rate and actual turn rate are quite close to each other.
It seems that the second GPS takes longer to have a low hdop. The erratic green line happened while I was trimming. However, when stabilized, first GPS has hdop around 0.7 and second GPS around 1.2. Both have M8N chip. It is true that examining both GPS logs, GPS 2 seems noisier.
However, I disabled GPS 2:
GPS_TYPE 1
GPS_TYPE2 0
and this is what happened:
Rover_20180702_251.BIN
Here is a log of altitude as shown by both GPS’s:
Status of both GPS’s:
The long logs (including mentioned above trimming) are due to not knowing a convenient method to start and stop a log. According to above:
On Plane and Rover dataflash logs are created soon after start-up. On Copter they are created after you first arm the copter.
Unless I miss something, I think arming and disarming should start and stop a log also in rover. At present I keep turning on and off.
So, in rover, how can I start and stop a log?
The podium of this circuit is a big structure of concrete and steel beams. Approaching to it a conventional compass its needle orientation is modified when approaching it to a podium steel beam:
Certainly lowering TURN_MAX_G the car goes slower and can stop completely, as can be seen on videos below. I left it finally at 0.3 (lower values don’t seem to change much).
In following tests I tried to increase speed, changing CRUISE_SPEED and SERVO2_MAX (left finally at 1600, as a safety measure). The main problem is the lack of trajectory repeatability: laps are different, and with same parameters you may have good laps, car going offtrack, or a crash against a barrier.
Other problem is reaching waypoint 1 after starting (beside podium). In many cases the car deviates and hits the right or left barrier.
Reason for this?
For following tests I trimmed waypoints and tried this mission:
For next three tests I tried CRUISE_SPEED=4.5, and six laps (repeating mission). First two failed and third succeeded.
In missions above trajectory fit to some waypoints is poor, particularily at 84. and at the videos it can be seen that the car goes offtrack after the long straight. Why poor fit in particular places?
Above it was mentioned unknown origin problems going from two gps’s to one. I wonder if magnetic problems would be improved with two external compasses. Common compasses are HMC5883 and HMC5983. A difference is that the second one has also SPI bus, so on the Pixhawk could be connected one to I2C as now, and a HMC5983 on the SPI bus. Module GY-282 supports choosing connection:
Will a HMC5983 on a GY-282 be recognized when connected to a Pixhawk through SPI?
A last thing about range finders, which I have began to consider. I have an analog one (1) on the left and an I2C (2) on the right. This is a log, which shows activity:
Briefly:
-Could I miss something when disabling second GPS?
-Why GPS status reaches 4 (undocumented)?
-How can I start and stop a log in rover without turning off?
-What about “Mag anomally” heard at times? How does it appear in logs?
-Reason for deviations at mission start, before waypoint 1?
-Reason for occasional steering oscillations?
-How can trajectory repeatability be improved?
-Why in certain points trajectory fit is poor?
-Will a HMC5983 be recognized on SPI? Will a second external compass do any good?
-Action when rangefinder 2 approaches an obstacle? (RNGFND2_TURN_ANGL does not exist)
Webillo,
Here’s some feedback from looking at the Rover_20180703_271.BIN log.
The speed control could be improved by setting the CRUISE_SPEED and CRUISE_THROTTLE a bit better. Could you try the method used in the video on this wiki page to capture these two values?
The steering contol looks pretty good.
It looks like the arming checks have been turned off. This is nearly always a bad idea. Could you try setting ARMING_CHECK = 1? You will probably see warnings when you try to arm, it’s best that we work through these warnings and resolve them instead of turning off the checks.
Now to answer some questions:
Could I miss something when disabling second GPS?
Normally more GPSs is better because we blend the results to get a value that is better than either single GPS. The track from the 2nd GPS is quite bad though, I’m unsure why - whatever is going wrong is within the GPS itself I think.
Why GPS status reaches 4 (undocumented)?
GPS Status of “4” means DGPS which is a very good lock. BTW, “5” is “RTK float” and “6” is “RTK fixed”. Each higher status is better. The documentation is a bit behind on the wiki but we will get to it eventually I think. The wiki is also all open so it’s actually possible for anyone to update it.
How can I start and stop a log in rover without turning off?
We don’t have a way to restart the logs I think but you can reboot the flight controller from the ground station. If using the Mission Planner it’s on the Flight Data screen’s Actions tab (bottom left). Set the top left drop-down to “Preflight Reboot Shutdown” and then push the “Do action” button.
What about “Mag anomally” heard at times? How does it appear in logs?
So this means that the compass reading does not match the other sensors (in particular gyro). It could be caused by the compass not being calibrated or it could be caused by external interference.
It is possible to view the magnetic field strength by opening the Log with the MP’s dataflash log viewer and then select “Sensors/Compass/Compass” from the drop-down in the middle below the graph area. the mag field strenght is normally shown in red and it’s formula is something like, sqrt(MAG.MagX^2+MAG.MagY^2+MAG.MagZ^2). This magnetic field strength should be stable if there’s no interference. There is always interference though but the more stable the better. If it changes by more than 30% then that’s a sign that there is too much interference.
How can trajectory repeatability be improved?
It’s hard to be sure but I think this might help:
Hope this helps…
Webillo,
Also could you try increasing EK2_YAW_M_NSE to 0.7 (or maybe even 0.8 or 0.9)? This parameter is mentioned at the bottom of this EKF wiki page but in short it reduces the EKF’s trust of the compass and instead makes it rely more on the gyros and GPS.
I’ll test all this shortly.
In the meanwhile observe this video:
CellSensor was at normal sensitivity. Compass should be at least 20cm away from motor; this happens if placed at the front bumper.
The ESC has no influence.
BTW, I assume that a compass at the SPI Pixhawk connector will not be recognized in actual version.
