After a few months of development we are ready to start beta testing Rover-3.5.0-rc1. Within a couple of hours the new version should be visible in the ground stations (including Mission Planner and QGC) using the Beta Firmwares link.
This is a major update and the list of changes is in the Release Notes and also copied below:
Changes from 3.4.2:
ChibiOS provides improved performance and support for many new boards including:
a) F4BY
b) TauLabs Sparky2
c) Furious FPV F-35 lightening and Wing FC-10
d) Holybro KakuteF4
e) Mateksys F405-Wing
f) Omnibus F4 Pro, NanoV6 and F7
g) SpeedyBee F4
BalanceBot support
Sailboat support
OmniPlus, OmniX frame support (vehicles can move laterally using 4 thrusters or wheels)
Auxiliary Switches expanded to many channels (see RCx_OPTION parameters)
External position estimates accepted from ROS and Vicon systems
Mode changes:
a) Follow mode (allows following another vehicle if connected via telemetry)
b) Simple mode (pilot controls direction regardless of vehicle’s heading)
c) Loiter can be configured to always drive towards target (i.e. does not reverse) (see LOIT_TYPE parameter)
d) Guided, RTL, SmartRTL will reverse towards target if DO_SET_REVERSE command received (via telemetry or as mission command)
Bug fixes and small enhancements:
a) RC and GCS failsafe timeout shortened
b) Object avoidance fix to include all sectors from proximity sensor (aka 360 lidar)
c) Safety switch ability to arm/disarm vehicle now configurable (see BRD_SAFETYOPTION parameter)
d) Onboard OSD support (for ChibiOS-only boards)
e) Gripper support
f) Sprayer support
This is the very first release candidate for -rc1 so although we think it is fairly reliable, there will undoubtedly be issues so be prepared to retake control in manual modes. If you find issues, please report them in this Rover-3.5 category and if possible include a dataflash log.
There is one known issues which we will resolve in future release candidates:
the RC7_OPTION parameter allows setting the feature controlled by the channel 7 auxiliary switch but this parameter has not been automatically populated using the 3.4.2 CH7_OPTION parameter. This means you will need to manually set the parameter to the feature you want. The Mission Planner’s Basic Tuning page may also not yet support easily setting the parameter so you may need to use the Full Parameter list or Full Parameter Tree screens.
Thanks very much for helping us beta test this new version!
Hi Randy! Looks good.
Question: Does this release include in-flight compass learning (Testers needed for in-flight compass learning)? I see the mention of a new “onboard compass calibrator” in the release notes, but it doesn’t mention “in-flight”.
Hi Randy, I just uploaded 3.5-rc1 chibios and the wheelencoders do not work. Here is a short log. I did not drive the rover around, I just powered everything up and turned the wheels by hand. Parameters are unchanged from 3.42 nuttx, except for RC7_option, which I set to Arm/Disarm. I tested this a while ago with 3.5-dev and with nuttx I was getting only random spikes in the rpm reading and with chibios nothing at all. The logs are in the Googledrive folder, too.
I’ve tried to reproduce this on my own balance bot but it appears to be working (for me). That doesn’t mean there isn’t a problem of course but just that i can’t reproduce the issue.
From looking at the logs it appears that the RPM values are changing.
One difference between my vehicle’s setup and your’s is that I’m using pins 52,53,54 and 55 but I’m not aware of any reason why this would make a difference.
By the way, we do actually have a known issue around using the wheel encoders for non-GPS navigation but this shouldn’t affect the reporting of the RPM to the GCS… but it probably affects the ability of the EKF3 to consume the data. We will need to fix this before Rover-3.5 can go live.
I will delete the older logs from the Googledrive folder. It looks like you opened one of the older logs. As the text states, this was 3.5-dev nuttx. With that version, I was getting rpm readings, but as the screenshot shows, they do not represent what the rover was actually doing. During that test both wheels where running forwards or backwards at a constant speed. I was using pins 52,53,54,55 before, but after testing 3.5-dev without success I changed the pins just to be sure ( I read something about it somewhere). It did not make the encoders work with 3.5, but 3.42 was working either way, so I did not change the pins back again.
The link in my previous post is still valid, now without the older logs.
I had BRD_PWM_COUNT 0 set before, while using 3.42, I changed it to 2 during testing. I just set PWM_COUNT 0 again, rebooted the pixhawk, but still no rpm reading.
The winch is not included I’m afraid. We can add it to the to-do list though (or you can of course).
I actually wondered when writing the winch feature for copter if anyone would ever use it. The special thing about the winch feature (in copter) is it has a rate controller that uses wheel-encoder inputs (some motors from pololu.com and other places have wheel encoders built in) to control the speed and length of rope deployed. The roboclaw motor controllers also have rate controllers built in meaning that someone could accomplish almost the same thing without using ArduPilot… sorry to waffle, it’s just that I’ve written other features (like the crop sprayer) that I thought would be useful but I’ve never found anyone actually using the feature even when they are doing exactly what the feature was designed for.
I see your point, I will have to put some more thought into how this will work.
I was thinking that I would have a depth sensor (like this) as well as water quality sensors, so then the winch would stop at a certain depth rather than relying of winch encoding. That’s the mechanical/functional side.
Then there is the code side, typical use would be taking 3 sensor reading at different depths, through the water column with boat in Loiter mode. I imaging that a Raspi would take the sensor data, somehow triggered by Ardupilot when depth is achieved from the winch/pressure sensor. I imagine custom code for mission planner would be need also.
I’m just piecing together parts and workflow at the moment.
No, I’m afraid stepper motors aren’t supported yet. It’s possible to buy a pwm based stepper motor controller (i.e. an ESC that accepts pwm but then converts that to a signal that stepper motors understand) but we don’t have native support in AP yet. I’ve got a couple here that I hope to get working but I better not make a promise about when exactly that will be.
Thanks Randy I have two ballbot running with stepper motors. I used the pololu tic controller and I’m still working on tunning but I can drive it around but only in manual. Other modes still have issues like in acro it osolates really bad in the roll or yaw axis. I’ll keep working on it and I’m working on a post of what I’ve learned at this point. Is there a way to tune acro mode aside from ATC balance
I also have two on brushes motors and my original Jason’s amp 2.5 rover.
So I guess there are no wheel encoders on the vehicle? I suspect it will be hard to get it to work well without wheel encoders.
For acro, the issue is probably the throttle-speed tuning. I heard from Ebin Phillips that he had to set CRUISE_THROTTLE to zero… but I’m unsure if this is correct because I haven’t used Acro on Balancebots much myself yet.
