I’m thinking about releasing Rover-4.4.0 as the stable stable. Although I think there are still some questions around L1 vs SCurves but I think we need to move forward and try and improve SCurves in subsequent releases.
What’s given me additional confidence recently is that I tested a BlueRobotics BlueBoat which was running 4.2 but then simply upgraded to 4.4 with no additional parameter changes and it worked great.
I’m interested to hear other opinions on this though.
I upgraded my boogie board from 4.2 to the latest dev version to test the autotune and had zero issues with that update. I am not the best person to give feedback but don’t think it would be a big deal plus it would be nice to try and keep releases even across platforms
Have you and Leonard resolved the WP radius/timing issue? That’s the only blocker I see. Otherwise, there are a ton of improvements that are otherwise lost by not releasing.
No issues with 4.4 on my rovers.
SCurves and the (related?) WP radius issues would make any waypoint navigation a bit of an issue - I’m hoping to assist with this in the coming months, now that it’s getting warmer outside!
I’d agree that it’s important to keep the rover synchronised with copter/plane releases as much as possible. It’s getting to the point where I’ve got clients running off a master on their vehicles, so they can get the latest features.
My yard has essentially died in the insane heat wave this summer, so my mowing has been limited to non-existent. I have an upcoming build with electric motors that I hope to use as a contrast to the hydrostatic drives on my primary mower that has become a workhorse test bed for Rover features. I’m eager for the heat to break, too, so I can be a little more productive!
Hi @Yuri_Rage,
Thanks for the reminder on the waypoint radius issue. I have put some time into this and the current status is that I see the same issue in Copter in SITL at least so I’m planning to discuss with @Leonardthall again.
I think there is still an issue. RCINxScaled works now in 4.4 beta7 but not correct.
When setting in Missionplanner/Setup/Mandatory Hardware/Servo Output:
Function = RCINxScaled then the full Range of PPM works only when the Trim is set to the min Value.
E.g. min= 900 Trim = 900 max = 2100.
When Trim is set to 1500 the min is not reached in the Output.
This means, it does not work as discribed in the Wiki.
Hi @Lorbass1,
Thanks for the report. If you’ve got a .bin log that would be great but in any case I’ll try and test myself.
Thanks for the reply. Sorry, I forgott you need facts.
Here in the pic to see: 1. With “assymetrical” Trim. 2. With Trim as usual. 3. Again with Trim at min Value
And here the link to the .bin File
(Strange Link-Text, I released the file for everybody)
I’m shure you will find the small bug. 
Another strange behavior in Mode Acro when after stop small Throttle Stick inputs.
RCOU_C3 produce outputs but below 1500 and this means reverse drive. While driving the control of
RCIN reacts normally.
Edit:
I’m confused about the neutral position of the throttle. In standard ESC’s for cars it is at 1500.
2000 means forward, 1000 backwards.
But as I recognized in Acro mode the rover moves forward with 1500. So I must reduce the throttle lower and this produce this mentionned reverse action when accelerating a little.
For the “Throttle issue” in Mode Acro I made a Video to explain it.
No idea why both videos can’t be started in this thread. In YT they works.
The complete Log is to finde at:
All Tuningsstep are completed as described it in the Wiki.
In Mode Manual all is working fine. Stick middle position produce an RCIN_C3 of 1500.
Switching to Acro the same middle Stick position produce an RCIN_C3 of 1000.
Realized by Curves in Taranis.
Here the application of a SIYI Gimbal Cam. At the end the Throttle issue in Mode Acro is good to see.
Hi @Lorbass1,
I’ve got a fix here (I think) to the RCINxScaled issue. SRV_Channel: fix RCInxScaled when input is range (instead of angle) by rmackay9 · Pull Request #25538 · ArduPilot/ardupilot · GitHub
If I create a binary for you to test with could you check it and make sure it behaves as you expect?
Here’s a Rover-4.5.0-DEV binary for the PH4-mini that includes the fix. This is 4.5 so it hasn’t gone through beta testing. It’s probably safe but after confirming the output works it might be best to go back to 4.4.
Hi @rmackay9 All I got was to register and / or install Dropbox. But there where no files in the 30days free of charge version at otto.kueng@lorbass.ch
Edit: Now the download worked. Will test it soon.
Hi @rmackay9 4-5.0 installed and tested.
Sorry, still the same problem. The output reaches not the min and max.
The limits of Channel 11 is a little special due to the needs of the Rover.
Hmm… I tested it pretty thoroughly including the edges.
Are you sure that the input PWM value is reaching RCx_MIN and RCx_MAX? When the RCInput reaches the RCx_MIN/MAX the Servo output should reach the SERVOx_MIN/MAX.
@rmackay9 May be I understood something wrong. I need I wider range of the output as the input.
And on the first pic for RC8 it works so, but not the range I set for Min/Max (850/2150)
RCIn is 995 to 1995 and RCOut 913 to 2087 and not 850 to 2150.
Hi @Lorbass1,
Re the vehicle moving in reverse when switched into acro, I think the problem is that SERVO3_TRIM is set to 1035. I think this should be changed to about 1500.
Re the Servo8 and Servo11 outputs not reaching the limits (e.g. SERVO8_MIN/MAX, SERVO11_MIN/MAX) as I mentioned above it looks to me like it is simply because the RCIn8 is not reaching the RC8_MIN/MAX.
In the image you’ve posted above of MP’s tuning page it looks OK to me. The ch8in (in green, aka RCIn8) is near 2000 (which is close to the RC8_MAX) and then the ch8out (in red, aka Servo8 output) is near 2100 which is what SERVO8_MAX is set to.
As others said, the WP_RADIUS setting isn’t working. This setting would help me a lot with my Rover, I’m running 4.5.0-Dev. Looking forward for a Fix!
Hi @DawidBoTak,
Thanks for the testing and feedback. Just so I understand better, the issue you’re seeing is that the vehicle is getting too close to the waypoint and is trying to make very sharp corners?
I think the issue remains: pivot turns overrun the intended endpoint because there is a logic error.
I think desired/correct behavior is this:
S-Curve nav cuts corners at greater of TURN_RADIUS or WP_RADIUS
Pivot turns consider nav leg complete within WP_RADIUS of waypoint
Present behavior appears to ignore WP_RADIUS when a pivot turn is prescribed, as previously discussed.
