Can pivot turns be setup for non-skid-steer config rovers?

ArduRover Rover 4.5
21

cool script. AI scripts way better than i do.
Is this the right track ? - Nope. Will it work - no idea.
I’d not go that way because -

  • complexity. Tuning is tricky, an extra layer of abstraction - no thanks.
  • not solving the problem - you are working around another.
  • go check this page - Tuning Pivot Turns — Rover documentation - check how many pivot parameters you will have to navigate. Your code seems to leave it to the chinese controller for rates, angles, angular accelleration…
  • not sure putting scripting into the critical control loop is wise. I’ve had no script performance issues, but if you did - then what outcome…
  • Failsafe - are these going to work.

Anything can be made to work - if it works easily, then excellent. My guess is you’ll be wishing for a simpler, supported config as soon as anything unexpected or unexplained happens.

VESC supports sensorless and a bunch of sensor options at least for BLDC. Im looking to add an AS5047 magnetic encoder, as the motors we recently recieved are without hall sensors. Its a bit of wiring, then a whole bunch of tuning… which may or may not solve my problem at hand.

22

I think @Paddy’s idea to use a lua script to basically convert the skid-steering output back into something the ESC understands is a good idea.

What’s there might work but I would recommend getting the steering and throttle values directly like this example script does.

2 Likes
23

I’m currently trying to work the math out in Java before writing the Lua, using the following test cases:

Example:

PIVOT_RIGHT(
  new SkidSteerLeftRight(MAX, MIN),
  new ThrottleAndSteering(MID, MAX)
),

MIN → lowest PWM value, or stick fully left / down.
MID → resting PWM value, or stick at center.
MAX → highest PWM value, or stick fully right / up.

In the above example, given that I want the left tread moving forward at max speed and right tread moving backward at max speed:

new SkidSteerLeftRight(MAX, MIN),

I should expect the resulting throttle and steering to be:
(throttle at rest, steering stick all the way to the right)

new ThrottleAndSteering(MID, MAX)

Conversely:

BOTH_MAX_FORWARD(
  new SkidSteerLeftRight(MAX, MAX),
  new ThrottleAndSteering(MAX, MID)
),

Given both left and right are full forward, the throttle should be full forward, the steering at rest. Etc.

Once I have all test cases passing I should have something approximating a mathematical solution to demixing. I hope =)

1 Like
24

@kazetsukai,

In case it helps, AP’s skid steering mixer is here. The saturation handling is the tricky part because AP allows changing the prioritisation of steering vs throttle. You could probably just ignore that though.

25

Am i missing something here? why are we trying to mix to skid steer output then unmix back to regular throttle and steering? why dont you just plug it into the regular throttle and steering output? it will still turn on the spot if you set it turning radius to zero should it not? we mix the outputs with boats and it works fine so it shouldn’t be an issue to just set it up as steering and throttle.

I think wp pivot angle also needs to be set for it to turn on the spot.

3 Likes
26

Hi @geofrancis,

That’s an interesting idea and I think you’re probably right… so basically setup both skid-steering and ackermann outputs (for steering and throttle) but only connect the ackermann outputs to the ESC/motors. AP will then think the frame can do skid-steering (which is true) and the ackermann steering outputs should actually work.

2 Likes
27

Interesting concept!

This is partially testable in SITL (and likely fully testable with a custom vehicle model I do not have the time/resources to create right now). Setting connected outputs to Throttle and GroundSteering while setting unused outputs to ThrottleLeft and ThrottleRight (leaving all other tuning values at their defaults/tuned values) results in a navigation behavior that ignores S-Curve nav for waypoints with course changes greater than WP_PIVOT_ANGLE. Unfortunately, the default SITL model just sits stationary after arriving at such waypoints, since the ground steering output alone doesn’t trigger SITL vehicle motion. I don’t think simply setting TURN_RADIUS=0 will do the trick, and I recommend setting it to a value tuned for vehicle performance.

Thus…on a vehicle like the OP’s, configuring as @rmackay9 suggests may well produce the desired result with no scripting or hardware changes. Ordinarily, I might call this a bug of sorts, but in this case, it’s a feature!

A word of caution: GroundSteering is not disabled when disarmed, so motor output will be possible in a disarmed state as soon as the autopilot is booted. So DO NOT issue RC steering commands while disarmed, or your vehicle will pivot!

4 Likes
28

A script to disable the steering when disarmed would probably be a good idea.

1 Like
29

I wonder if simply setting the min/max/trim values all equal to the centerpoint would do that?

Then set them all appropriately when arming state changes to armed.

I may have a few minutes to test that later this evening.

2 Likes
30

Yep, I can confirm this does happen =)

I will look at the above parameters and test… I’m close on the demixing but not quite there.

1 Like
31

Skip the Lua script and try what Randy suggested (and I briefly tested) above, first.

We can probably use Lua to help tame the disarmed behavior, instead of remixing everything.

1 Like
32

what if you set it as an omni vehicle? with steering done by motor output 1, that would fix the disarm problem. it woud also fix the Ackerman reverse problem.

so have :

motor 2 to controller throttle input.
motor 1 to controller steering input.

you will need to enable motor 3 and 4 to get rid of pre arm warnings.

omni vehicles dont use differential thrust to steer using 2 and 4 so they mirror each other and behave exactly like regular throttle output.

motor 1 would be yaw control and technically lateral but you can just set rc in minmax for roll input to 1500 to ignore that. It doesn’t do anything in any mode other than manual anyway.

image

33

I did a very quick test this morning before work- Seems like pivots are working now, but the mower oscillates. I think other steering-related tuning at fault and that we can call this a success in terms of pivot turns:

Positioning also seems like it starts off okay, but drifts as the mower is in motion… likely other mistakes in config I will need to narrow down. One suspect are the drive motor fields interfering with the compass data- see this image:

Rover_rear
Rover_rear1008×756 312 KB

I plan to use RTK, but wanted basic stuff working first.

1 Like
34

Promising results, but obviously not ideal. How does it drive in ACRO mode? Tuning there first is usually best.

36

Nice ! - so close !!
QGroundcontrol is great operationally once setup and working, but i find mission planner way better for getting things going - better tuning. xtrack_error and pid_desired vs pid_achieved (both for turning and for speed) are useful for figuring stuff out.
I’ve resolved a few motor issues, that were the motors running in the opposite direction to that commanded by ardupilot. Watching the PWM values commanded, and seeing what happened identified those problems.
I’d try a square mission with 4 waypoints much further away from each other (5m+), and im guessing you are using compass for direction.
cheers