Did everything as you said.
Left joystick left-right now controls the servo, right joystick down only controls the motor.
Thank you very much for your help! 
Here is the file with the changed parameters. ArduPilot-Parameters-28082020-1634.param (24.9 KB) Maybe there is still something you consider improvable.
The rovers RC3 trim is at 1099, the same as RC3 min. This is the reason why you can only control the throttle in one direction. It might be a kink of QGCs calibration process. I never used QGC for a complete setup of a ardupilot vehicle. Only as a planning tool after setup is complete.
RC3 trim should be at 1500, so the ESC uses input below 1500us for reverse and above 1500us for forwards.
Thank you very much, now it works in both directions! 
@count74 So, everything is working and we’ve also stabilized some of the wirings so that there are fewer cables hanging around loosely. Testing the vehicle on the ground however I have noticed that it is rather fast and even a minimal up- or downwards tilt of the joystick causes the vehicle to speed away almost uncontrollably.
Do you have an idea perhaps how the movement of the joystick can be manipulated to create less vehicle speed? Looking at the parameter file, I don’t see a parameter like “speed” that stands out. Thank you already in advance for your help.
Yes, that is the problem with most RC cars. They are build for speed.
Your car uses a brushed DC motor
(two cables from the ESC to the motor) if I remember correctly from the pictures. It should be able to start and drive slow.
The easiest way to slow the car down, would be to reduce the PWM range of the servo output the ESC is connected to. So change servo3_min
and servo3_max, so they are closer to 1500us (servo3_trim). They should be around 1000 and 2000us now.
Try to set them to 1200 and 1800us for example.
There are self calibrating ESCs, which learn the input range during operation. The above method does not work for those ESCs.
I have changed the parameters to 1700 and 1300, and it seems to be going a little slower now.
The ESC is a Tamiya TBLE-02S, which can work as brushed and brushless, but as far as I am concerned it is not a self-calibrating ESC.
Thank you for your help!
@count74 Sorry for bothering you again, but what exactly are these AHRS issues?
Here is the log file: ArduPilot-08092020-1019.txt (4.3 KB)
All I see on the map is that there is a huge offset between the GCS and the vehicle and that the GCS is in the wrong place as well. The point of the vehicle moves around at random as well and the GCS position has an offset of about 20m to 30m to its actual position.
Actually, both the GCS and the vehicle are only centimetres apart, as I have them both right in front of me on the table.
Do you have an idea what could be causing this offset?
Thank you already in advance for your help!
EDIT: I believe it has something to do with the roll pitch and yaw angles (AHRS), right?
But this still doesn’t explain the gigantic GPS offset to me …
EDIT 2: I think that a compass recalibration might be necessary … last time, I calibrated compass 0 since there was too much intereference, causing the calibration process to be incredibly long and fail in the end. Could that cause the high GPS offset?
Where do you test? What device is running the GCS software? Where does it get its position from?
GPS is very unreliable indoors.
Even outdoors normal GPS is only precise to a few meters and may be influenced by many factors (power lines, foliage, etc.)
AHRS errors usually go away as soon as the rover has a solid GPS fix.
AHRS uses EKF, not only the gyros.
I’m running the GCS on my MacBook, and it gets its position from the WLAN. As I’m setting up indoors, the WLAN position does not differ much from the physical position of my laptop.
I would do the actual tests outdoors, but I don’t want to do the whole mission set-up outdoors. We don’t have any power lines near, so there shouldn’t be too much interference here.
Precision to a few metres would already be good; on the map, the positions (especially that of the vehicle) are sometimes almost a kilometre away from the actual position.
EKF is an Extended Kalman Filter, right? So would I go according to this https://ardupilot.org/copter/docs/common-apm-navigation-extended-kalman-filter-overview.html in order to get the GPS working?
I have also found this https://ardupilot.org/dev/docs/extended-kalman-filter.html#extended-kalman-filter, which might be useful as well …
Thank you already in advance for your help!
If you are testing indoors, you can not expect to get a reliable GPS fix and because of that, AHRS and EKF errors will not go away. There is nothing you can do about this, except for going outdoors, away from buildings and other obstacles. The GPS antenna works best, if it has unobstructed view in all directions down to the horizon.
Unobstructed view in all directions is not possible due to the location of my home.
But I can take the vehicle outside and see if that does anything for the GPS.
So this is what I got right after setting everything up.
–––––––––––––––
The GPS position of the vehicle is properly now, the one of the GCS is still roughly 20m differing from the actual position.
I can’t start the mission because I’m being told that the battery percentage is below 40%, but checking the status LEDs of the LiPo it still has about 60% … so I don’t know what’s up with that. I will just set the barrier percentage lower and see what happens.
––––––––
Okay, so there is no BATT parameter that allows me to edit the barrier percentage … unfortunate.
–––––––––––––
Setting the flight mode to AUTO, the vehicle quickly moved backwards and then collided with a wall (it’s not damaged). So I think it might work when I test again in the backyard.
Unobstructed view would be the best case szenario. GPS or better GNSS will work with partial view of the sky, just not as accurate/reliable. The GNSS receiver that came with the Pixhawk 4 is a Ublox M8N. It receives US GPS and russian Glonass satellites at the same time. This means it has more satellites to calculate its position from, even with partial view of the sky. I get 14 to 16 sats in our backyard.
The battery monitor can be calibrated.
It needs a factor to multiply the partial voltage reported by the power module to get the actual battery voltage. Missionplanner calculates that factor for you, if you enter the meassured voltage.
I never used QGC for that, but I guess it has a similar function.
Just had a look at the PM07 manual and Holybro states a voltage factor of 18.182 and a current factor of 36.364 Amps per Volt.
Testing/tuning never starts with auto mode (and never without a GPS lock and indoors). Auto/guided mode is the last step. You need to tune Acro and Steering mode first to get a reliable base for the navigation controller. With an ackermann steering vehicle you need to adjust the servo min/max position so the servo does not try to move the steering over its mechanical limits. This may damage the servo and the autopilot may command steering outputs, beyond what is mechanical possible.
Here are two videos by Randy Mackay (one of the ardupilot developers) on how to tune a rover:
Acro tuning:
Speed/throttle tuning:
Thank you for this information and the videos. I will have a closer look at them and test everything again tomorrow; I will let you know how things went then.
ACRO Mode is behaving unexpectedly.
Steering moves extremely slowly, meanwhile the speed is quite high.
If I tip the right joystick slowly once, I will only have the speed for that time. If I push the joystick through entirely, the full speed will remain until I tip the joystick in the opposite direction once.
Also, the steering sometimes does small movements on its own.
I place the vehicle on a bucket because the first attempt in ACRO mode sent it flying straight into a wall. I’m happy for the large front bumper, otherwise, the vehicle would most likely be in shambles.
In STEERING mode, it behaves similarly when it comes to speed control, but the steering doesn’t move at all.
ACRO mode.param (24.9 KB) STEERING mode.param (24.9 KB)
I haven’t changed the parameters yet, but here are the files from the vehicle being in ACRO and in STEERING mode. These modes behave incredibly different from the MANUAL mode, so I’m kind of concerned.
Do you have an idea what could cause this behaviour? CRUISE_THROTTLE is at 50%, so I don’t really understand why the vehicle is being this much faster than usual.
Thank you already in advance for your help!
Did you watch the videos I linked to?
Manual mode just passes through the RC input to the servo outputs (only mapping the RC input values to the servo output values and mixing in case of skidsteer/tank vehicles).
Acro mode is the most basic driving “assist” mode, trying to keep the vehicle at a commanded turn rate and speed. For that it needs a solid GPS fix and some tuning. The case that a rover works well with the default values is extremly unlikely. For the cruise throttle setting you need to assign a switch for “cruise learning”, switch it on and drive the vehicle at the desired cruise speed for a while (with a GPS lock) and switch “cruise learning” off again. Cruise speed and the corresponding throttle value should be saved. It is all explained in the videos.
Yes, I watched the videos. The developer went into ACRO mode and then started changing the parameters based on how he manipulated the graphs.
But in my case, a simple movement of the joystick caused the vehicle to go full speed and not return to zero after letting go, making it crash into a wall at full speed.
I also believe that there was still a mission overlaying, because it showed me later that the vehicle drove a mission, even though I had it disabled. I cleared it all again and then there was no overlaying mission anymore.
My main problem was that the sticks were reacting completely different from expectation (e.g. stick movement causes full speed, does not return to zero on zero but on tilting through to the other extreme once and shortly).
Furthermore, I need to check if ArduPilot on QGroundControl displays the same graphs somewhere that were displayed in MissionPlanner in the video. I do have a laptop that runs MissionPlanner, but it is significantly older and slower than the one I’m currently using, so I’m worried that it causes errors just because it can’t keep up with the changes.
Did you do the cruise learning first?
It is done in manual mode and should prevent the vehicle from speeding away in acro mode later. Also make sure everything works in the right direction. Forward should be PWM values over 1500us, reverse below that. Right steering should be above 1500us, left below. This is not mandatory, but keeping this consistent makes troubleshooting a lot easier. To test if the autopilot really corrects the steering in the right direction (gegensteuern),
switch to acro (rover disarmed) and pick it up. Turn the rover left and right and the steering should go in the opposite direction.
Oh no, sorry, I didn’t do the cruise learning first. My bad.
I will do test these things tomorrow and let you know how it went.
Thank you for this valuable information!
Servo 1 and 3 are the only ones that have a function, according to the parameters.
On the neutral position of the left joystick, the front wheels are slightly tilted to the left, and not precisely forward-facing. Moving the joystick to the left tilts the wheels to the left, and right to the right.
The motor/throttle does nothing.
This is all for when the vehicle is disarmed.
When the vehicle is armed, the steering doesn’t do anything, but the throttle works.
I have no idea what is causing these problems when it all worked just fine a few days ago. The GCS constantly loses the communication, too, so this is all really bothersome right now. 
