Rover-3.5.0-rc2/-rc3 is available for beta testing

Update to Missionplanner beta and you get 3.5-rc2.

Thank you for that.:smiley:

@David_Boulanger Which autopilot, and which pins?

?? I think you have the wrong member here.

@peterbarker I think you’re after @count74

I think there is a problem changing the motor output of an OMNI-X rover for anything but RC-PWM.

Having the ph4 with ardurover 3.5.0-rc2 set up to work with RC-pwm out as an OmniX.
changing MOT_PWM_TYPE: from 0 to 1, 2, 3, 4 or 5 does not change the type of signal.
MOT_PWM_TYPE: 3 (brushed with relay) does change the behavior, but not the type of signal. Instead of 1500 (servo*_trim) being neutral 1100 (or Servo*_min) becomes neutral.
This is what i would expect expect but without an RC-PWM signal. Brushed would mean a 0-100% duty cycle output, right?

(I know 5 shouldn’t work, because its on the i/o pwm out port (i’m on a pixhawk 4 and a Cube, both with similar behavior).
But oneshot125 and brushed should not need any changes in settings from rc-pwm right? and work on the io and on the fmu -pwm ports.

Just to check my setup i kept MOT_PWM_TYPE 4,
changed Frame type from 1 to 0 (undifined instead of omniX),
Servo1_function to 73 and 2 to 74 (skid steer)
And it worked the way i expect it to, a dutycycle pwm output on i/0 pwm out on the PixHwak4.

I also managed to get servo1 = motor1 to be brushed-PWMout
and servo3 = motor 2 to be RC-PWMout (mesured on a scope) while missionplanner did not show any differances between 1 and 3 (except 33/34 function)

ps, BRD_PWM_COUNT stayed 8 the whole time.

if you need a specific logfile or other info i’m happy to provide it.

1 Like

@peterbarker
It is a Pixhawk 1 (2.4.8) and the hall sensors are connected to four of the AUX pins.

@Nando,

Thanks very much for the report. I’ve confirmed that at least OneShot is not working on Rover so I’ve added it to our to-be-fixed list here. I’ll need to have a chat with @tridge who knows more about the OneShot setup but hopefully we can get this sorted for -rc3. Thanks!

1 Like

I just noticed, that 3.5.0-rc2 is shown in MP as firmware under “Install Firmware” , but after I installed it, it shows as 3.5.0-rc1 under “Messages” and in MPs window bar.

1 Like

Did you get to the bottom of this problem. I’m looking to give rc2 a try but not even going to get the boat ready until this is solved.

I just tried to load it. Although Mission Planner say rc2 beta it says rc1 in my messages. And it failed the same bench test that rc1 failed a bit ago so I would assume it is in fact rc1. In auto with no waypoints it fails to go into hold and after a period of time the motors start running.

1 Like

@count74, @David_Boulanger,

Thanks very much for the report. You’re absolutely right that something has gone wrong with the build server and although it claims it’s got Rover-3.5.0-rc2 available, it’s actually loading -rc1 for at least some boards.

If you’re using a Pixhawk or Cube you can manually load the fmuv3 version by downloading the .apj file from this directory and then use MP’s “Load Custom Firmware” link.

I’ve added this to our list of Rover-3.5 issues and hopefully we can sort this out soon.

1 Like

O.K… I have a pixhawk 1. I’ll get the .apj

1 Like

Well I’ve done this before but it is not working. I saved the link to the apj file. When I try to load it I get this message. I know I’m probably doing something silly or forgetting something.

@David_Boulanger,

I suspect somehow the html file is being downloaded instead of the .apj file so it may help to download this .zip file that includes the fmuv3 version of Rover-3.5.0-rc2.

1 Like

Good job. Its loaded in and will bench test today and give it a work out on Wednesday. Thanks for everything.

@rmackay9. Just bench tested and all looks O.K… The only difference is if put into auto with no waypoints Mission Planner says something like " failure to change flight mode" instead of going into hold. It stays in the last flight mode which in my case is steering. I have a 2 hour workout for it tomorrow. a little auto mission and a lot of loiter for video work. Anything you need checked out? I may do the waypoint mission with throttle and ackerman steering and the long loiter part with differential plus ackerman.

1 Like

David,

Those tests sounds good, thanks very much for testing!!

The issue behind the “failure to change flight mode” is the new EKF failsafe which we added in response to some reports of “drive aways” (from @ktrussell I think) and I also saw it happen in our simulator.

If the EKF doesn’t have a good position estimate the vehicle will refuse to go into an autonomous mode. There’s essentially two “gates”:

  1. if the vehicle is disarmed, the vehicle can’t be armed in an autonomous mode. It is possible to arm in a manual mode.
  2. if the vehicle is already armed (in a manual mode) it won’t be possible to switch to an autonomous mode

As always though, the EKF failsafe can be turned off by setting the FS_EKF_ACTION parameter to zero.

1 Like

@count74, @David_Boulanger,

We’ve gotten to the bottom of the build server issue which stopped -rc2 from going out for the “fmuv2” boards (which are older Pixhawks with a 1MB limit). I’ll be releasing -rc3 later today but it will be exactly like -rc2 but will have this one issue fixed.

Txs!

All went good today. Ran a mission with throttle/ackerman, same mission with differential/ackerman, and then loitered for about an hour with differential/ackerman. Although differential/ackerman doesn’t really work well in reverse it loitered just fine with the stern into the wind. I have not looked at logs yet but if you need one for anything let me know.

1 Like