Rover with Skid Steering won't move in AUTO mode

ArduRover Rover 3.1
1

Hello all

I’m new to the Ardurover but have some experience in PX4.

I’m having a lot of trouble getting Ardurover to work in AUTO mode, although it works fine in Manual mode (turning, throttle, all OK). I’ve spent many hours with this, googled everywhere, read forums, but can’t sort it out, so desperate for some help.

I’m using a Pixhawk with APM:Rover 3.1.1 with a tank style rover, with ESCs that don’t have reverse.

RCMAP_PITCH=1
RCMAP_ROLL=2
RCMAP_THROTTLE = 3
RCMAP_YAW = 4
( My Taranis radio is set in Mode 2 , Pitch channel 3 and Roll channel 2 )

I’ve connected the ESCs to PWM Main 2 and Main 3 ( Main 1 and Main 3 combo doesn’t work)

I’ve had to set RC2_TRIM and RC3_TRIM = 900. If I set them to 1500 when the Pitch stick is centered the rover advances, and I can only stop it when moving stick to bottom.

I can’t arm with radio, only thru Mission Planner, but that’s not an issue at the moment for me.

I have a number of waypoints set and I can load them back and forth from Mission Planner to Rover and viceversa. I press Auto when more than 10m away from the waypoint.

When I press AUTO nothing happens, the rover gives an initial stutter and then nothing. If I rotate it in place sometimes the tracks move briefly like if it wanted to change heading, but it’s a very subtle movement.

When I try STEERING mode the behaviour is quite difficult to understand. One of the tracks on the side starts moving and stopping, but I can’t correlate it to heading or anything I do with the sticks. To be fair I don’t really understand what Steering is supposed to do so a bit confused here…

I have tried all the settings in the different pages, http://ardupilot.org/rover/docs/tuning-steering-and-navigation-for-a-rover.html and others… but I have not found a combination that works.

EKF fails continuously, don’t know why, so disabled it so that arming check passes.

These are my settings:
ArduRover_params.param (8.7 KB)

Any help much appreciated.

2

@ealdaz,
The PX4 and the Pixahawk are two different Navigation Controllers.
It also sounds like your ESCs are not programmed to have reverse. The ArduRover firmware is expecting to be controlling RC Car ESCs that have both forward (2000 us) and reverse (1000 us) with Pitch (throttle) neutral at 1500 us.
Regards,
TCIII AVD

3

Hi Thomas
Thanks for your quick reply.
PX4 is such an unfortunate name, it is both Hardware and Software. I was referring to the PX4 flight stack, not the controller.

Correct, my ESCs don’t have reverse and can’t be programmed to have it.

From what I understand from your email should I conclude that the Manual mode and Auto mode program the PWM outputs differently? I was not expecting that …

In Manual mode I’m able to control the rover perfectly, and would have thought that Auto mode would have worked with the same PWM ranges i.e. from TRIM value to MAX value for forward motion and MIN to TRIM for reverse. I was expecting that not having reverse would have some effect in some type of manoeuvres like spinning on the spot, but not that it would stop the rover from moving completely… I find it hard to understand…

Is an ESC for reverse my only option here? If so can you recommend one ? ( < 10 A is fine )

Thanks
Eduardo

4

I should add that I’m using a very simple rover, the two motor version of this one : https://www.sparkfun.com/products/10336
with two brushed motors.

5

I use Dimension Engineering Sabertooth DC motor ESCs.

Regards,
TCIII AVD

6

Your mention on not having reverse made me think that perhaps AUTO was trying to do a in the spot turn, so found a setting called PIVOT_TURN_ANGLE and it seemed to at least do something… although it hasn’t solve the issue.

Then I went back to suspecting that the firmware is not happy with a value of TRIM of 900 and really expects a value of 1500, because on reboot often I find that RC2 keeps getting reset to 1500, it seems to be hardcoded or something…

So then thought I would put the rover on a stand so that wheels don’t touch the ground and set both TRIMs to 1500… Surprise then it doesn’t respond to throttle or roll anymore… wheels won’t move at all in Manual mode.

IN desperation I went for the default setting of RCMAP_ROLL = 1 , RCMAP_THROTTLE = 3 and switched the ESC from PWM MAIN 2 to MAIN1 … but same result… I can only control rover in Manual mode with both TRIMs at 900. When I put them to 1500 I can’t control the rover, no response to throttle or roll…

It seems to me that either I’m missing something basic or there is something strange going on with the PWM output logic…

Is it possible to install an older version of Ardurover, to check if the behaviour is the same? If so how?

7

Hi,
I look rapidly at your parameter
AHRS_EKF_TYPE should be 2

On your RC 1 and 2, the min should be under the trim
And If you don’t use the safety button you can put BRD_SAFETYENABLE to 0

For AUTO mission you need to have arm your rover otherwise it will not move !

8

So it turns out that the main issue is that the code expects ESCs with reverse as @TCIII mentioned ( I don’t really understand why this is the case, as reverse is not strictly necessary for motion but it seems to be hard coded this way)

So if TRIM is not 1500 AUTO doesn’t work. ( Manual works fine with ESCs without reverse, which adds to the confusion)

With new ESCs that have reverse I can at least get repeatable behaviour, i.e. it goes off in one direction and it seems to be able to follow a straight line. This is progress.

However I can not understand what the AUTO function is doing, the heading it chooses to go on has nothing to do with the Direct to current WP heading or with the Target Heading as indicated by M.P.

The only thing that seems to do something that makes a bit of sense is the RTL

Is anyone experiencing anything similar?

I’m running Rover v3.1.2

9

After a little more testing it seems that there is an 180deg error between the waypoint heading and the actual heading of the vehicle.

ie. when the vehicle reaches 180 deg from the waypoint heading the vehicle stops turning and starts moving, but in the opposite direction to the waypoint.
That is when it points in the opposite direction to the waypoint ( see image) it assumes that it’s going in the right direction and starts moving.

So it would appear that the internal heading value used for navigation is not the same as what is shown in MP, ( which corresponds to the actual physical heading of the Rover)

This is very strange… any ideas…?

10

To clarify a bit, the red line indicates the current heading and the orange line indicates the heading to waypoint.
They are off by 180 deg

Why would this be?

11

I’ve installed the latest beta and now finally everything seems to work fine, none of the very strange behaviours I had previously, both in the behaviour of the rover and on what I was seeing in MissionPlanner ( see Rover with Skid Steering won’t move in AUTO mode )

I did have a royal battle to get the compass to give me a heading that made sense in my Pixracer. Ended up disabling all the internal compasses and only using the external and using declination to correct for the offset from that compass…

Although I’m trying the 3.1.2 version and I thought arming was fixed I still can’t arm with the radio transmitter ( Minimum throttle and roll max right is the way to do it?)

Thx

12

i seem to be facing a strange issue with the RTL command of the Ardurover.

i am using the APM 2.5 with Cytron MDDS10 Motor Driver ( https://www.cytron.io/c-93-dc-motor-driver/p-mdds10 ) which works just fine in manual mode when controlled by a Turnigy 9x running ER9x

now i did add waypoints to the rover and then downloaded those to see if they were written correctly and they were there in the APM. I have set SKID_STEERING_IN to 1 as i am using Skid Steering. Also the MP Radio Calibration i have kept channel 1 (ROLL) to reverse.

now when i put the rover in RTL or AUTO it just started going round and round with varying speeds.

i am trying hard to get this solved for past 15 days but now finally today i have posted it for someone on this forum to help me out.

thanking you all in advance.