A new version of Rover is on it’s way out for beta testing. It should appear in a few hours in the Mission Planner (and other GCSs) using the “Beta Firmwares” link.
Changes vs Rover-3.2.0-rc1 are in the release-notes.txt but also written below:
MOT_SKID_FRIC parameter allows increasing power for skid-steer vehicle pivot-turns
Bug Fixes:
speed nudging fix in AUTO mode
throttle slew range fix (was slightly incorrect when output range was not 1100 ~ 1900)
PID desired and achieved reported to GCS when GCS_PID_MASK param set to non-zero value
use-pivot fix to use absolute angle error
Probably the change that people will appreciate the most is the MOT_SKID_FRIC parameter. If you’re using a skid-steering vehicle and have found that it won’t rotate on the spot well then please try increasing this parameter from 0 to 100 (or something in between).
There is still one important outstanding issue which is that in Auto mode the vehicle won’t do a pivot-turn at a waypoint. We are still working on this issue - it’s surprisingly challenging but I’m sure we will sort it out.
I am testing 3.2-rc2 right now. Both wheel encoders are working now. I had one bad IR sensor and to many encoder fields on the motor. Now I reduced it to only 4 per track (from 24), because above a certain RPM it would read zero again.
Two questions, which encoder should be left, which right? And how are the ticks per wheel calculated?
I now entered 192 for wenc_cpr, because 4 fields per track x 4(?) x 12 (12:1 reduction). I have to clean up the cabling, then I will test the rover outside.
Now I thought I had figured out, which encoder should be on which wheel, because the wiki says WENC_POS_Y positive is left from the COG or FC. I entered the numbers in MissionPlanner and hey, MissionPlanners´s parameter discription says positive is right from the COG/FC. I am lost.
Is there any way we can get the final release of version 3.2 to be able to receive twist msg instruction from mavros/mavlink. Currently it is not handled properly.
At the moment, ardurover ignores any Twist or TwistStamped message published over ROS topics.
We implemented a workaround. If the incoming mavlink message has zero yaw rate and non-zero velocity, interpret it as setting velocity. Otherwise, if it has zero velocity and non-zero yaw rate, interpret as yaw rate. Set the ignore flags accordingly. But this won’t work if we are trying to set a non-zero yawrate and a non zero throtthle at the same time. Which is crucial for course correction.
@rmackay9 This is good news! Won’t be able to test this on the boat just yet as we need the “pivot in auto-mode” to work on that system. I want to test this on our wheeled test-rover as soon as possible… First snow hit today, but it shouldn’t last. Designing and building a tracked rover ( a “tank”) is next on my list.
@meat030 Yes, pivot turn is the same as spot turn (IMO).
Now, for the moment, we haven’t specified which encoder is for which wheel. It will be important for ardupilot to know which wheel is associated with each encoder when we start using them for control (currently we only use them for position estimation). We could do that by looking at the POS_ values… or we could just assume that the first wheel encoder is for the left motor and wheel encoder 2 is for the right motor. I think it would be safest (to save yourself from rewiring later) to do it this way (1st encoder = left wheel, 2nd encoder = right wheel).
The pivot turn (aka on-the-spot turn) in AUTO is still on my to-do list for this release (Rover-3.2.0)… I attempted to resolve this in a fancy way (involving switching from the L1 controller to the angle->rate controller during pivot turns) and it didn’t go well so I will fall back to the simpler pass-a-massive-lateral-acceleration-request-into-the-L1-controller method and see how that goes.
I still have trouble with 3.2-rc2. I never had problems setting up rover before. Look if manual is working as expected, then switch to steering and look if it is actually counteracting uncommanded turns, then tune PIDs.
With 3.2, I can not get consistent results in steering mode. I set everything up so both wheels go forward with higher PWM signal, main out 2 set to 73 goes to the left wheel, main out 3 set to 74 goes to the right wheel, viewed from behind the vehicle. I hold the rover in my hand in steering mode and since pivot turning does not work, I apply a little throttle and turn the rover left and right. With very little throttle, it actually counteracts the turn with one wheel going backwards, so it seems to work alright. If I apply more throttle, it also shows the expected behaviour of one wheel slowing/going faster to counteract. Then at some point this behaviour suddenly changes and the rover is steering into the turn. I could not believe it at first and thought I observed it wrong, so I tried several times, but it is actually doing it. Here is a log:
Sebastian,
Thanks for testing. I haven’t looked at the log yet but I wouldn’t expect steering mode to work correctly if the vehicle isn’t actually moving because steering mode is a lateral acceleration controller and the calcs very much depend upon the speed of the vehicle. I suspect what you’re seeing is that the vehicle thinks it’s traveling backwards. In earlier versions of Rover, Steering mode did not work correctly when traveling backwards (the vehicle would turn in the wrong direction) so I think this is the sudden reversal of wheel direction that you’re seeing.
There could very well be other issues in Rover-3.2 of course, we have changed a good number of things.
Thanks for your reply Randy. I disabled GPS now and I am testing indoors with the wheel encoders. A strange thing I noticed is that the steering direction changes when going from pivot turn to driving backwards in manual mode. Pivoting clockwise and then giving reverse throttle results in the rover turning counterclockwise. I am still testing steering mode…
I too have just tried rc2 and it appears to have done away with the dreaded BAD AHRS. The next issue I’ve encountered is with the POZYX navigation. While my Y axis movements are tracked correctly, my X axis movements are tracked backwards i.e. positive x movement is tracked negatively.
Setup
Skid steer - 2 wheel platform with 2 casters (aka like a wheel chair)
max robot speed is 0.5 m/s (its a slow robot)
robot weight is 90 kg
I’m also seeing issues of pivot turn not working in steering mode with zero throttle.
When rover not moving pivot turn does not work.
Also in steering mode when I provide any steering input the robot is very slow to turn to either side.
infact I can’t call it even a turn. It is still trying to track straight.
putting the robot in reverse (again in steering mode) does the same. standing behind the rover (rover back is facing me) and pushing the throttle reverse and giving a left command. I see the rover approaching me while trying to nudge to my left. Same is also true when I give a reverse throttle and push the right throttle stick. I see the rover approaching me and slightly nudging to the right.
Correct me if I’m wrong but is it a good way to tune your robot in steering mode? i.e. drive robot up and down while tweaking the ATC and nav settings ?
I noticed there was a commit 2 days ago for “allow pivot turn in STEERING mode”.
Does that mean turning issues will be resolved soon. Happy to help out in testing if I can
Is there a way I can tune my robot in steering mode before trying in auto?
The weather forecast for tomorrow does not look good. Is there a way I can test the tuning parameters indoors by putting it into steering mode and driving it up and down indoors and see how the robot responds to turns commands?
Sorry for taking so long to reply, in any case, the way the vehicle’s steering direction changes when changing from forward to reverse is normal behaviour. It’s consistent with a regular steering vehicle. So imagine with a regular steering vehicle, if the steering stick is held right, when driving forward, the heading of the vehicle moves in the clockwise direction (i.e. it turns right) but in reverse the heading of the vehicle moves counter-clockwise (i.e. it’s nose goes left).
It’s possible we could add a parameter or something to allow the user to decide the behaviour in reverse. Remember that for the higher controllers (whether pilot or autopilot) we want skid-steer vehicles and regular steering vehicles to be consistent… which is why, by default, we’ve made skid-steer vehicles steer like regular vehicles.
If you’re happy with some alpha testing then feel free to upload this to your Rover if it has a Pixhawk2/Cube (although a recent PH1 should also work). What’s different is the MOT_SLEWRATE parameter now limits the steering response on skid-steering vehicles. A lower value limits it more, a higher value limits it left.
This changes is most visible if you do this on a skid-steering vehicle:
hold the steering stick to the left or right, throttle stick slightly forward.
while keeping the steering stick as it was, pull the throttle stick into reverse.
In -rc2 there would have been a sudden jump in the motor outputs as it moved from forward to reverse. This transition should be smoother now.
