Wait, your the baseline to your base station is 14km?! That’s a fairly long ways for L1-only, and with a horizon surrounded by trees, I can guess that the GPS navigation would be a little less reliable. With a local base station <1km away, I would guess that you could actually get a GPS fix (instead of bouncing between 3D fix and float all of the time)
We can see GPS.Status in log 36 bouncing erratically between 4 and 5. I’m assuming 4 means DGPS and 5 means RTK.
Looking at GPS.Status from the quadcopter log in August Simultaneous_Copter_20180822_30.bin, we can see it is rock-solid at 4.
Is it possible to defeat the RTK to see how well that works? The quadcopter seemed to work fine without it. I think that would be a worthwhile experiment.
Alternatively, I would bring the car closer to an RTK station, say within 1 km, and attempt Auto driving some waypoints. I’m envisioning something simple in a parking lot near the station. First see if GPS.Status stays constant at 5. If so, then see how well the car stays on the waypoint path. If not, then pursue electromechanical fixes to get it steady at 5. If not steady at 5, then using RTK is maybe actually hindering progress.
4 is 3D Fix, 5 is RTK Float, and 6 is RTK fix. Roughly 2.5, 1, and 0.1 m accuracy respectivley. Bouncing between a RTK float and GPS is going to have a lot of movement because non-RTK position is uncorrected. It would actually be better to totally eliminate RTK because of the on-off nature of signals that are being received.
1 Like
1 Km?
Placing the base
“Typically the distance between the reference station and local rover shouldn’t exceed 10-15 km…”
The circuits are 14 Km away.
This is GPS Status with the same GPS installed on a drone moreless 15 Km away from the RTK station with a clear sky:
This is GPS Status with the same GPS on the car on the big circuit on the succesful mission above:
That is the RTK station I have. The circuits cannot be moved and the trees cannot be cut. With the RTK GPS the targets are:
-On the big circuit add DO_CHANGE_SPEED waypoints and improve lap time. How can I brake the car?
-On the small circuit try a Balance Bot:
GSoC 2018: Balance Bot with Arduino
if knowing how to make it work with stepper motors (not DC motors).
Now with the best mount point I get acceptable results on both circuits, and even I could drive an 1/8 R/C bike against the car doing this mission:
Clearly the 1/8 R/C bike wins.
On four of the five mount points available Mission Planner shows the RTK station coordinates with many decimal points (same as the coordinates published by them). On the virtual one MP reports a virtual station 4 Km away from the circuits; however the results are the worst. I’ll consult the RTK station people about this.
I suggested that as an experiment only. Information gathering. Data collection. A quick way to figure out whether RTK lock is the only problem with the car or not.
Imagine if you ran my proposed experiment, RTK proved solid at status 6, yet the car still occasionally wandered. You would say, “Aha! I just wasted several months fixing something that was not the root cause.”
Imagine if you ran my experiment, and RTK was still jumping around from 4 to 5. You would say, “Aha! The problem is not distance from the station or trees, but maybe an intermittent electrical connection.”
Maybe the experiment would show solid 6, and the car is cured. You would say, “Well, there is the problem but until Ardurover developers can fix the guidance algorithm to stop being so sensitive to change in GPS status, I need to give up on RTK altogether and rely on DGPS only.” After all, the quadcopter worked fine without RTK, right?
No matter what, in one test session you would get a wealth of information. In my opinion it would help identify a solution quicker than the approach you have been taking.
I hope this helps. I want to see your car running lap after lap at 20 m/s held to the path like a slot car!
New experimental experiments:
-Two RTK GPS’s on car.
-Tests on RTK station.
-Swarming.
Two RTK GPS’s on car.
Having got another XL RTK GPS for mounting an offroad rover, I first tested it as a second GPS on actual car. At the same time, reference station was improved (Glonass added on a mount point, and perhaps something else).
Recall that on post 37 july 2 above I had problems with a single GPS (conventional), with no clear reason.
These are the results with two mount points (good and almost equal) on the 2m wide circuit at 1.3m/s:
With these good results I tried at 1.6m/s:
It is clear that speed was too big. The car had to be repositioned many times.
Tests on RTK station.
Better than trying on a place closer to the RTK station, I tried on the RTK station helped by two people working there, who were very kind and showed great interest on these experimental experiments, with both RTK GPS’s on the car.
The reference point appearing on Mission Planner is at the white dome on the center of the photo. I tested the car on a rooftop moreless 40m from it.
Results were not so good, but this was a first contact:
-RTK fixed (status 6) was difficult to get.
-Fewer satellites than at the circuit.
-The new RTK GPS was on RTK fixed more often than the old one, and with its logs more stable.
-The expensive GPS instruments they had were affected by the 433MHz 3DR antennas. A final test was done without these antennas, with the Pixhawk connected to the laptop with an USB cable, and the car quiet.
Later I saw that from a previous test I had GPS_MIN_ELEV = -60, so for a next test I will leave the default value. This next test will be a mission at moreless 1m/s, since, although there was not too much space, I could drive the car:
This is the tlog video:
Swarming.
I have added to simultaneous copter rover mission video (post 57 august 22) above the tlog videos:
Unfortunately:
-the copter lost waypoints (irregular waypoints joining);
-the antennas on car and drone were horizontal (this will be changed), and communication was lost at times.
Instead of having a common mission on drone and car, and start each one independently (first car, next drone) I plan to try swarming with car being the leader and drone the follower. I don’t know if this can be done, and if the drone will follow the car being it at 0m height (perhaps offset when “Update Pos” button is pressed, with drone above car, would be maintained).
So I asked this on:
Swarming with Mission Planner
Response: the Empty Set ø.
Empty Set ø (Wikipedia)
1 Like
Rover-Copter swarming: seems to work. This is an initial test:
The car was not armed (moved by hand).
On all tests above from day one the 433 MHz antena was horizontal, since it was mainly used for programming the Rover, and was easier to place. GPS’s on roof were separated from electronics, but not too much, since their compasses were not used.
But these 3DR 433 MHz antenna seem to affect GPS RTK lock. With CellSensor:
Posts: 100 mm. Small 433 MHz antenna in vertical position for a better overall data transmission. GPS Status was continuously 5 (RTK float) during this test, being acquired fast.
Above:
“…The new RTK GPS was on RTK fixed more often than the old one, and with its logs more stable…”
What probably happened is that the old RTK GPS was closer to the 433 MHz antenna than the new one.
1 Like
Here is another video (4K) with the two RTK GPS’s on the big circuit, with the two 3DR antennas vertical (no data loss as can be seen on the tlog interval), and with both GPS’s raised and with beter shielding:
Log:
20190211_RTK2_Asoger_92.bin
Speed was increased to 4.7 m/s, which resulted critical:
Speed changes are clear in above video.
Although both GPS’s status was 4 or 5 during the mission, it was seen as 6 (RTK fixed) occasionally during the rest of the session:
That happened roughly during 15s, with the car stopped.
The mission starts beside the drivers rostrum, so the car passes three times beside it on the three laps mission, and an aditional one till reaching the final waypoint. GPS shadowing is clear there:
At 4.7 m/s desired cruise speed it is hitting your throttle servo limit often.
This results in the actual speed to never reach the desired speed. I would think this is imposing a lot of error on the control loop.
I recommend relaxing SERVO2_MAX limit so 4.7 m/s is more easily within the capability of the car. I think that would result in tighter control and more stability.
I noticed something in your logs. Accelerations measured by IMU1 seem nice and quiet but IMU2 is quite noisy. Look at this period when the vehicle is at rest. IMU2 has X-acceleration noise exceeding ±0.05 m/s² while IMU1 noise is around ±0.01 m/s².
Same thing for Y-acceleration. IMU1 is nice and quiet while IMU 2 has 8 to 10 times the noise.
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?
I think that reducing noise on IMU2 or disabling it would do two things. First, it would clean up the calculated position estimate, and second, it would enable reducing parameter EK2_ACC_P_NSE, which would make the Kalman Filter trust the IMU more and the GPS less.
Same thing with your gyros. Look how much noisier IMU2 gyro is, again when the vehicle is not moving.
Limitation:
SERVO2_MAX=1600
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.
Also:
SERVO2_MIN=1000
SERVO2_TRIM=1517
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:
Sensors:
-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.
Anyone?
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
http://ardupilot.org/rover/docs/parameters.html
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?
Above:
“… 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.
Now:
ATC_ACCEL_MAX 2
ATC_BRAKE 1
ATC_DECEL_MAX 0
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:
ATC_ACCEL_MAX 0
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.