Ive got a 4 wheel steering rover that I make work by taking servo5 function and driving it from the steering channel, and then reversing it (so wheels turn opposite of each other). Everything works fine in manual mode, but when I use guided mode, the steering spaz’s out and turns left right left right. If I turn servo5 function off then it works fine. I have tried different channels, wp_radius, and reversing roll nothing seems to work. I am using latest update of mission planner, with latest firmware of ardurover, on the pixhawk 2.1 cube. Why would this happen only when servo5_function is set to steering (26)???
It looks like it could be a bug in the firmware. I had it working on an older version (3.1.2 I think) so I loaded that up and it seems to work fine no problem.
As for the latest 3.2.1 firmware, this is how I would setup for 4WS
Servo5_FUNCTION = 26
If I reverse the direction of servo5, then it seems to work fine and doesnt slap left and right turns. If I put the channel back to normal (So F/R turn opposite directions), then it slaps left and right.
I put 3.1.2 back on, set RC5_FUNCTION to 26 (I guess the lingo changed in the later firmware), and it works fine.
Id like to use latest firmware. Strange that I cant adjust the turn_radius function in the older firmware as it is greyed out in basic tuning, and doesnt show up under full parameter list. I know I had used it in the past, so thats strange. Is there any discussion about an issue like this? Can I report it somehow?
Hi Bryan,
Any chance you could put a dataflash log somewhere so I could have a look at it? We’ve changed a lot of code between 3.1 and 3.2 so it certainly could be a bug but it could also be some other kind of configuration issue.
I’d never considered this as a way to enable 4 wheel steering, thanks for this!
Bryan,
I just tested this in the simulator and it seems to work. That doesn’t mean that there’s no problem of course, clearly there is, it’s just not super obvious what it is yet.
I think it would be good to check the SERVO5_MIN, _TRIM and _MAX are close to the SERVO3_MIN, _TRIM and _MAX values.
In the graph below steering is being output to channel 1 (red) and channel 5 (blue) with SERVO5_REVERSED = 1 so it’s output is the mirror image of channel1.
One last thing, in case it wasn’t clear, I’m pretty sure you’ll need to reduce the ATC_STR_RAT_FF (attitude control steering turn rate feed-forward) when the rear wheels are enabled for steering because the response will be twice what it will be with just the forward wheel enabled for steering.
Awesome, yes that crossed my mind while switching firmware about the min and max values for the rear steering. Ill give that a try and adjust the ATC_STR_RAT_FF value as well.
How would I go about creating a dataflash log? I am not familiar with the process.
Also when Im switching firmware it doesnt seem like it erases parameters which is fine, If I get everything working on the older firmware, do I just save a config file specific for the older firmware, and then one for the newer? I notice between the two firmwares that it doesnt interpret the parameters exactly the same.
Thanks!
Checkout this page’s “Downloading Logs via MAVlink” section.
Firmware upgrades don’t wipe parameters and as much as possible, during the upgrade we try to automatically convert any parameters that have changed. We almost never changing the scaling of a parameter as part of an upgrade, more commonly we rename the parameter especially if it’s going to be interpreted differently.
It is generally OK to download parameters to save them away and then load them back later if something has gone wrong although trying to limit the upload to just the parameters that really matter is perhaps best. For example the parameter that start with ATC_ do all the attitude and speed control. the NAVL1_ does the navigation. Anyway, do what you can, it’ll probably be OK.
Here are the files:
Hi Bryan,
The issue is clear as day, the ATC_STR_RAT_P value is far to large. It should never be larger than ATC_STR_RAT_FF. This isn’t mentioned on the wiki so I will add that.
I think it would be good to set the ATC_STR_RAT_P and I values to zero for now, tune up the ATC_STR_RAT_FF value until it turns reasonably well, then start increasing the P and I values a bit.
Here’s a graph of the STER message’s DesTurnRate (desired turn rate shown in red) and TurnRate (the actual turn rate, shown in green) and we can see that it’s overshooting massively so some gains need to be reduced.
Then we can look at the PIDS (PID contribution for Steering) and see it’s all coming from the P. Really we should mostly be steering on Feed-forward (shown in orange). My guess is P should be reduced a lot (even to zero for now) and ATC_STR_RAT_FF probably needs to be increased a little.
Your the man. Ill work on that thanks! The log was done with the ATC_STR_RAT_FF at .1 (pulled down from .2 like you recommended) Where should this value be?
Bryan,
My guess is that 0.1 is a bit low so perhaps 0.2 is better. It’s being so swamped by the P at the moment that it’s hard to get more detailed on what the value should be.
By the way it’s possible to graph the desired and achieved turn rate in real-time if there’s a telemetry system connected. Details are at the bottom of the tuning-steering-rate wiki page.
This is a bit of a learning experience for all (including me) and I suspect we will update the default parameters for Rover-3.3 so that more vehicle work out of the box.
I will continue tuning next week. In the meantime, do is there a way to pull a log for navigation position vs time?
Bryan,
The POS message has the time, Lat and Lng values in case that’s helpful.
By the way, I created this developer wiki page which provides an overview of Rover’s navigation code. I don’t necessarily expect you to dive into the guts of Rover’s code but thought it might be useful to various people as a reference at least.