Rover-3.5.0-rc3 has been released for beta testing and can be downloaded using the ground stations’ “Beta Firmwares” link. The changes are in the release-notes and also copied below:
Changes from 3.5.0-rc1
ChibiOS fixes and enhancements to many boards including Pixhawk4
EKF failsafe added and checked before entering autonomous modes
Object avoidance enabled in autonomous modes (Auto, Guided, RTL)
Cruise speed/throttle learning always runs for 2 seconds (saves user from having to lower switch)
Boats hold position after reaching target in Auto and Guided (also see MIS_DONE_BEHAVE)
MAVLink message interval support (allows precise control of mavlink message update rates)
Bug fixes and minor enhancements:
a) DShot ESC support
b) Auxiliary switch 7 parameter copy from CH7_OPTION to RC7_OPTION
c) Wheel encoder offset fix
d) SmartRTL default num points increased to 300
I think this should be quite close to a final version we could release as the official version so any testing people here can do would be greatly appreciated. If you see any problems please post them here or in a new topic in this Rover-3.5 category.
Thanks!
P.S. -rc2 and -rc3 are exactly the same except -rc3 includes a build server fix that was stopping -rc2 from going out for some boards.
I am still trying to get the encoders on my robot to work and I might have found the problem. I use latching hall sensors on the outside of the outrunner motor as encoders. Since they are working in 3.4.2 nuttx and are not working in 3.5 chibios, there had to be something different in the way the input pins are handled. Is it possible that there are internal pullups active in 3.4.2 and disabled in 3.5? I just added an external pullup (shoved a resistor in the back of the servo connector…) and I am getting RPM readings in MissionPlanner.
It’s possible but I’m afraid I don’t personally know ChibiOS to that level of detail. Perhaps @peterbarker or @tridge knows. By the way, Peter made a fix to the wheel encoder code in master after Rover-3.4 went out - I can’t remember exactly what was wrong in 3.4 but my understanding is that it was certainly a bug fix. I have certainly tested the pololu motors with wheel encoders (described on the wiki) and they are working with Rover-3.5.
Mission Planner still has 3.5rc1 as the beta firmware. I suspect it will change in a day or 2. No rush. I just had a little free time today to load and bench test it. I realize there are other ways to get it but I’m not real good at it and in no rush.
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.
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!
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.
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.
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.
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.
