Rover-3.4.0-rc1 released for beta testing!

Kornel,

To switch into Loiter you’ll probably need to set one of the MODEx parameters to “5”. Once Rover-3.4 becomes the official release then the mode will appear in the flight mode setup screen in Mission Planner (and other GCSs). I’ve added a note to the Loiter mode wiki page as well.

RoboBill,

Great, thanks for the testing and report! I’ve created an issue here to track the reversed bug. I think it will be an easy fix.

1 Like

Hi Kevin,

Thanks very much for testing! This really helps.

Re acro improvements, I’m guessing but it could be the reversing control improvements. If ATC_BRAKE was set to 1 and the speed controller momentarily set the throttle output to reverse (in order to slow down the vehicle) the skid-steering vehicles could suddenly turn the wrong way.

Great work!

Slight bug in the changes to AR_AttitudeControl at line 509:

// acceleration limit desired speed
float speed_change_max;
if (fabsf(desired_speed) < fabsf(_desired_speed) && is_positive(_throttle_decel_max)) {
speed_change_max = _throttle_decel_max * dt;
} else {
speed_change_max = _throttle_accel_max * dt;
}
` return constrain_float(desired_speed, speed_prev - speed_change_max, speed_prev + speed_change_max);`

You check if _throttle_decel_max is positive before applying it, but not _throttle_accel_max. If _throttle_accel_max is set to 0, then the vehicle never accelerates, whereas the parameter notes say that 0 should give unlimited acceleration.

Also, if throttle_decel_max is zero, then you become limited by your ACCELERATION max.

This would be my suggestion (noting I don’t understand the role of the abs on the speeds):

if (is_positive(_throttle_decel_max)) {
    _dec_change_max = _throttle_decel_max * dt;
}
else
{
    _dec_change_max = 1000; // Or something similarly huge
}
if (is_positive(_throttle_accel_max)) {
   _acc_change_max = _throttle_accel_max * dt;
}
else
{
    _acc_change_max = 1000; // Or something similarly huge
}
return constrain_float(desired_speed, speed_prev - _dec_change_max, speed_prev + _acc_change_max);

It’s not quite as streamlined, but it covers acceleration and deceleration and behaves as documented for the zero case for each.

1 Like

Also, did you say you’d fixed the sudden deceleration at each waypoint? If you set up a very high deceleration rate and a low acceleration rate you can still see the vehicle slow down dramatically every time it passes a waypoint.

With more sensible values, it hides the deceleration (e.g. decel of 10).

Hi @mroberts,

Yes, we’ve mostly fixed the sudden deceleration after passing waypoints. There are still two situations where it accelerates or decelerates too quickly:

  • if the vehicle is put into Auto mode while disarmed and then armed, the desired speed will immediately jump to the CRUISE_SPEED/WP_SPEED. The work around for this issue is to arm in another mode and then switch to Auto.
  • at the end of a mission (when vehicle reaches the WP_RADIUS around the final waypoint), the vehicle switches into Hold mode and the throttle output is immediately set to zero. The vehicle will likely have slowed before reaching the waypoint but the vehicle will still likely come to a slightly sudden stop.

Both these issues are captured in this issue so I’m pretty sure we will fix them in a follow-up release. These issues are not new though.

Ah, thanks for the note on finding the code issue re the accel/decel. I’ll have a look at it or perhaps @Ammarf will.

I’m comparing sim performance between 3.3 and 3.4. I find that 3.4 makes MUCH wider turns than 3.3. Running both at 1.0m/s gives the same performance, but where 3.3 followed the same path at increasing speed until you hit turn_max_g, 3.4 seems to increase the turn radius as you increase speed.

Is it possible to upload logs here?

I’ve increased the turn radius in SIM_Rover.cpp to 5m (otherwise it’s very hard to replicate due to minimum speeds). This is for a conventional steering rover - have the other people in the thread been running skid steer?

The biggest change in the code I can see is the removal of the 1/speed scale factor in AR_attitudeControl, but that seems like removing that should INCREASE the steering input, and make it turn tighter (comparatively) as speed increases - you’re no longer dividing the error by 5 for example.

1 Like

A little video of Position Holding with 3.4rc1. It also ran a survey grid flawless. https://www.youtube.com/watch?v=XujtYIUTDnA&t=124s

Impressive performance!

David,

Great video. I think it’s quite clear when the vehicle is switches into Loiter that it initially drifts and then it behaves like it’s front is caught on a string (which is how it should act). Thanks!

Boat loiter looks like it’s working very well indeed. Can’t wait to test myself!

Is there anywhere I can find out about the Omni Rover support?

Thanks to everyone working on this project, it’s amazing stuff!

Russ,

Re the omnirover, I think we will add a page to the Reference Frames section of the wiki and also add a section to the Motor and Servo wiki page but I’m afraid for now all I have is a picture. There’s only one motor configuration supported at the moment which is three wheels positions at 120degree increments around the frame. the SERVOx_FUNCTION values for the three outputs should be set to motor1 (33), motor2 (34) and motor3 (35) respectively.

That’s no problem, thanks for getting back to me. These are very exciting developments!

Greetings. Very good development of beta tests v3.4.0 rc1. An incredible video clip. I have a question: I want to use the Loiter mode for an inflatable fishing boat with a 3,3 m long. I’m using a 30 lbs DC submersible motor. I’ve also set up a preset model. There is no good test of orientation of the model to a given point on a mission. The servo 1 is 360 deg and has a gear with i = 2,5. Is this configuration of mechanics appropriate? Do I have to set additional parameters?

@rmackay9, I’ve been digging into the changes to AR_AttitudeControl and AP_MotorsUGV and I’ve found something that makes me go “hmmm”.

3.3: AR_AttitudeControl applies a 1/speed scaling factor in calculation of the steering output through the PID, then constrains the result to +/-1.0 before returning it. That steering is then sent out unchanged in AP_MotorsUGV.cpp

AR_AttitudeControl.cpp line 253 from this change: https://github.com/ArduPilot/ardupilot/commit/5563691bd1ced5cca2f91d0a78a8e7845e853c09

3.4: You remove the 1/speed scale factor in AR_AttitudeControl (so the calculated values will be a lot larger), but you still constrain it to +/1 before returning it.

The output (now constrained to +/1) then gets divided by the speed in the updated AP_MotorsUGV - line 410 here: https://github.com/ArduPilot/ardupilot/commit/3db2cc700ea994e4edc38302a5645ba172ba48af

This (I think) explains some of the funky behaviour I’ve been seeing where servo output is clipped at high speeds in Acro mode. If my servo range is 1000-1500-2000, the most steering I can get at 10m/s is 1450 or 1550. Set up 3.4 with a high turn_max_g (like 7), a high FF (2), and speed_turn_gain of 100%, then run your kart track at 10m/s. It will go nuts, but if you watch the ch1out, once it’s at speed it will never go outside of 1450-1550.

The same thing in 3.3 will show a greater range of steering output.

I think the fix is removing the “constrain” at the end of get_steering_out_rate, and from “set_steering” in AP_MotorsUGV to leave the clipping to the final output.

The alternative would be to do the speed correction / scaling in mode.cpp (calc_steering_from_lateral_acceleration) since that’s where you have a direct link between the steering and the velocity, just before it gets sent to g2.motors.set_steering(). There’s almost no need for the motor to manage that side of things. (IMHO).

It wont show up at low speeds if your required steering is less than 1/speed % - i.e. if you need less than 20% steering at 5m/s it wont clip.

1 Like

Really nice analysis.

I totally agree. Actually I hit this issue yesterday on my high speed boat. I just could not get it to turn quickly at high speed even though it would turn on a dime in manual mode.

When I made the change you’ve found, I recognised that this could be an issue (it’s mentioned in the PR but that reaches a limited audience) but hoped that we could get away with it. I might work on this today.

I guess you would vote for us holding off on Rover-3.4 release until we fix this? I’m keen to release 3.4 but lose of steering control on high speed vehicles is a serious issue so I think we probably have to fix it first, then release -rc2, test that and then finally release 3.4 officially.

EDIT: I’ve got a fix here that I’m testing.

Given that the lane following looks close to being done, could you incorporate that into 3.4-rc2 with a flag to turn it off - it’s not entirely clear from the lane following how to disable it.

Re your fix, it doesn’t look like you’ve removed the +/-1.0 constraint at the end of AR_AttitudeControl - that’s the critical one.

1 Like

@mroberts,
Txs, I’ve removed the limit from AR_AttitudeController and created a PR to get this fix into master.

Re the lane based throttle control, I think it might be best to push that out in a point release (i.e. Rover-.3.4.1) so we can get 3.4.0 out sooner.

David Hello! Can you post your full parameter list for 3.4.0-rc1

This is it.3.4 beta initial.param (11.9 KB)