Hi,
I am coming to the end with my wits. I have skid steered rover with two separate motor controllers, RTK GPS and Pixhawk Cube. The thing is that in manual mode everything work like a charm. However, as soon as I switch to AUTO it goes nuts! Usually spinning on the spot. I have checked pretty much everything that I thought could have caused this. As I am finishing this project as my master’s thesis and time is running out any help or pointers would be greatly appreciated.
Strange. Guided exactly the same. Acro and steering is weird and jerky and running circles as well. I have simplified all the PIDs to just P term, because I have suspected over-integration. You can have a look at some live data. They are steering PID desired and archived and heading error.
Auto:
I have tuned PID loops for many years in industrial controls, BUT Ardupilot is a bit of a different beast because of the Feed Forward terms, so, I may be wrong, but at least in just looking at it from a pure PID standpoint, you need to add some integral. It is common for a proportional only controller to settle and be “happy” away from the setpoint. That is what it looks like with your achieved being nearly perfectly parallel to your desired. Integration of the error term will bring it into the setpoint.
However, after another day od testing and playing with the regulators it seems that it runs ok and more or less towards the waypoint if it is on the left side of the rover. It goes nuts the second the heading overshots just a bit to the left (waypoint is on the right) and starts spinning. I think that it implies more fundemental error and I doubt the problem is with the terms ballance. I would understand bad dynamic in the steering if the PID parametrs were just a bit off… As you say, entirely different beast.
There something very wrong with your tuning values. Your rover seems to be relativly fast, if it reaches 3m/s at 50% throttle. Since it is a skid steering rover, steering should then also be quite sensitive. All your tuning values seem to be to high for a responsive rover. A “FF” of 20 should never be necessary, in any case! It is far beyond the recommended limits. It means “steering input times 20” goes into steering output. Feed forward is used to drive the output (steering in this case) in the desired direction, so the rest of the PID algorithm does not have to cover the entire range of output. A “D” value of 0.1 is also pretty high and might destroy your motors/gears sooner or later.
Yeah as I said it was a wild gues out of desperation. It does pretty much the same with sensible values like these:
It almost looks like that the regulator works with bad data or the interpretation is wrong because the control variable u(t) has only one direction (± doesnt change) so it works only in one direction and thus adds to the heading error.
No problem, shoot away! The trims make sense, since my motor controller takes something like 1000-1900 for 0-100% power and bit value of 0 or 1 on another pin for direction. So 950 means motor off with some safety margin.
Problem solved! I am ashamed as hell to admit that I have switched polarity on one motor. However, the reason it worked flawlessly on manual is that when i moved my pitch stick forward the pixhawk took it like roll stick and vice versa so the two mistakes perfectly neutralised each other. I was already nose deep into the source code trying to fing “a bug” when found this out. At least now I understand the inner working of steering to the last dot Thank you guys for your help!
Thank you guys for your help!