Rover-3.2.1-rc1 will soon be available for beta testing. It is going through the build server as I write this so within a few hours it should appear in the Mission Planner’s Install Screen’s “beta firmwares” link.
Changes are listed in the Release Notes and are also copied below:
APM:Rover V3.2.0-rc1 25-Aug-2017
Changes from 3.1.2:
Skid-steering vehicle support added (i.e. tank track or R2D2 style vehicles)
Brushless motor support
Improved speed/throttle and steering controllers:
layered P and PID controllers with optional feedforward, input filtering and saturation handling (reduces unnecessary I-term build-up)
forward-back acceleration limited (see ATC_ACCEL_MAX parameter)
pro-active slowing before waypoint in order to keep overshoot at or below WP_OVERSHOOT distance
proper output scaling for skid-steering vs regular car steering controls
TURN_RADIUS parameter added to allow better control of turn in Steering mode
speed along forward-back axis used instead of total ground speed (resolves unusual behaviour for boats being washed downstream)
Auxiliary switch changes (see CH7_OPTION parameter):
“Save Waypoint” saves the current location as a waypoint in all modes except AUTO if the vehicle is armed. If disarmed the mission is cleared and home is set to the current location.
“Learn Cruise” sets the THROTTLE_CRUISE and SPEED_CRUISE parameter values to the vehicle’s current speed and throttle level
Wheel encoder supported for non-GPS navigation (can also be used with GPS)
Visual Odometry support for non-GPS navigation (can also be used with GPS)
Guided mode improvements:
for SET_ATTITUDE_TARGET accepts quaternions for target heading, valid thrust changed to -1 ~ +1 range (was previously 0 ~ 1)
COMMAND_LONG.SET_YAW_SPEED support fixes (thrust field accepted as target speed in m/s)
SET_POSITION_TARGET_GLOBAL_INT, _LOCAL_NED fixes and added support for yaw and yaw-rate fields
Bug Fixes:
resolve occasional start of motors after power-on
steering mode turn direction fix while reversing
reversing in auto mode fixes (see DO_REVERSE mission command)
We still have a fair bit of work ahead of us to update the wiki to explain all the changes but here are a few tips:
to setup a skid-steering vehicle set the appropriate SERVOx_FUNCTION to 73 (left motor) and 74 (right motor). So for example if the left motor was attached to Pixhawk’s MAIN AUX 1 pin, set SERVO1_FUNCTION to 73.
the speed/throttle and steering tuning parameters all start with ATC_
motor related parameter start with MOT_ (i.e. throttle min and max have been moved here)
Yes, that’s definitely in the plans! We just need to make sure all the lower end functionality is working well first. In particular the throttle and steering control rewrite was a pre-requisite (in my mind anyway).
Just wanted clarification on brushless motor support.
What does this exactly mean from a software perspective?
Does it mean …the APM can send full PWM signals to a motor controller as opposed to RC PWM signals?
Im currently using a maxon controller and in the future will use roboteq motor controllers in my robot. Currently the plan was to send RC PWM signals to the motor controller (which is supported) but it would be nice to send just a regular PWM pulse to the motor controller to get better output resolution
So I think Rover can send “regular PWM pulses” instead of the RC PWM signals. It’s basically the same feature as we use to drive the skyrocket drone motors which are brushless. My rover doesn’t make use of this but I’m pretty sure Nick used this for his rover (see MakerFaire blog posts).
By the way, there’s two different types of brushess motor support. One is “Brushed With Relay” and the other is “Brushed BiPolar”. Now, I’m a bit new at this so not sure if those names are good or not but the “Brushed With Relay” type of motor seems to have a relay input and if we send a high voltage it spins in one direction, low voltage and it spins in another. The “Brushed BiPolar” seems to control the motor direction with different PWM values only (i.e. no relay pin in)
I know that Pierre @khancyr would like to expand the motor controler class to encompass higher end type of motor controlers. That is an interesting avenue but it might be getting quite complicated to support.
Take the roboteq controler for example, it has its own pid loop controler for the encoder, would you use this one that is optimal for the drive or use the ArduRover that is less optimal but better integrated with the EKF?
In this case I could be fine to have the option of not using the ArduPilot pid but still expose the encoder signal to the EKF. I am pretty certain this can be added as a parameter, but we need a bigger roadmap for these future options/addons
Are you able to point me to the blog post. I’m struggling to get the motor controller to recognise my non rc pwm signal. I’m currently using a maxon motor controller to control my brushless dc gear motor
Currently, I’m using ardurover 3.2-rc1 — will get around to upgrading to rc2 soon.
I noticed that when using mission planner, when I goto
Initial setup -> mandatory hardware -> radio calibration
to check out my RC input signals.
I noticed that if I check the reverse checkbox on throttle, my throttle stick becomes a roll input and starts turning my rover either left or right. My roll input also becomes the throttle. This is ofcourse incorrect as I would expect that when reverse is checked on the throttle, forward becomes backwards or backwards becomes forward.
The opposite is also true. When I check the roll reverse checkbox. my throttle become the roll input and my roll input becomes throttle. very weird
Here is my setup
Currently running in skid steer mode
I have a mode 1 transmitter … using pitch for throttle and roll for turning left and right
Thanks for the report. That is weird behaviour but I think there is an explanation. I think the issue is actually in the mission planner. The reverse checkbox is likely setting the SERVOx_REVERSED parameter instead of the RCx_REVERSED parameter (or maybe it’s setting both).
We should report this in the mission planner’s issue list including the steps to reproduce. https://github.com/ArduPilot/MissionPlanner/issues. I can do this or someone else can do it but in any case, for now, don’t hit that checkbox and instead set the RCx_REVERSED parameter directly in the full parameter list… or better yet, just use the reversed setting in the transmitter (if it has one).
Will this have an effect in steering or auto mode …
currently I have RC2_reversed (steering input channel) . My transmitter has all the input controls in its nominal (non inverted state)
I am able to spot turn in steering and auto mode (thanks to the latest changes to the code) and it does spin in the correct direction.
however in STEERING MODE when I give a left or right steering command while giving a bit of thottle the rover hardly reacts to the comands. It stutters alot when moving straight. I can see that it does slowly veer left or right but it is very very slow and not smooth like in manual mode.
This is perhaps your first time using steering mode? Steering mode drives a lot like AUTO mode because it uses the same “L1” controller (which is a target position -> lateral acceleration controller).
… however @khancyr has made a change so that pivot-turns will work in Steering mode from the next version so you’ll find you’ll be able to turn it on-the-spot like in other modes in the next beta release (coming soon). Still, it will not drive like a manual mode…
