It has been a long time coming, but we are finally ready to do a new release of the APMrover2 firmware. The new release will be called 2.40, and is available now as a beta release.
Before I go into the new features, I'd like to offer a big thank you to Tom, Linus, Greg, Stephen and Chris for helping so much with this release. We have had a rover development call each Friday morning for the last few weeks, and each call has moved the code forward a lot, with great feedback on the testing done during the week.
I'd also like to set expectations a bit. This won't be a perfect release. We've changed a lot of code and added a lot of features, so it is only to be expected that we've introduced some bugs that haven't been caught yet in our testing. I'm expecting that we will probably have another release soon when we get feedback from more users. The reason we are releasing now is that we think this is a better firmware than the existing stable release, but you will still have the option of loading the old release via MissionPlanner if it turns out there is a critical bug in the new code.
If beta testing turns out OK for the next few days then I expect to do the 2.40 release early next week.
If you want to just dive in and try the new beta release then this is what you need to know:
- you can download a prebuilt firmware for all board types from http://firmware.diydrones.com/
- the auto-generated documentation for the new parameters is available here
- the wiki documentation is not up to date. Hopefully that will be fixed soon!
- this release changes the EEPROM and DataFlash format. This means all your settings will be lost, so back them up! It may also take up to a minute on the first boot to reformat your DataFlash
- The MissionPlanner hasn't yet had a new release since the addition of the new Rover modes, so the modes will show up incorrectly. As soon as Michael does a new release it should be fixed
Now on to the good stuff, new features! The key new features are:
- support for skid steering
- support for dual sonars
- completely new failsafe code
- support for auto-start using a trigger pin
- support for auto kick-starting
- speed scaling of turns to reduce the chance of a roll over
- scaling of throttle on waypoint approach and turn
- more control over obstacle avoidance
- new 'STEERING' mode for testing auto-tuning
- support for the PX4 board
You'll have to wait for the full documentation for a full explanation of the new features, but I thought I'd explain some of them now to get you started.
Skid Steering
You can now control a tank-track style vehicle (skid steering) by setting two parameters, SKID_STEER_IN and SKID_STEER_OUT. The SKID_STEER_IN parameter tells the APM that RC input channels 1 and 3 (which are normally steering and throttle) should be assumed to be motor speed control from a RC transmitter setup for skid steering, such as the sort of transmitter that may come with a RC tank. The APM will map those channel inputs onto steering and throttle.
The SKID_STEER_OUT parameter tells the APM that you have a skid steering vehicle, and that output channels 1 and 3 control the left and right motor respectively.
Notice that you can set these two options separately. This is to allow you to use a traditional RC controller with a tank if you want to.
The code doesn't yet know about turning on the spot with skid steering - that will have to come later.
Dual Sonars
If you look through the parameters in the "advanced parameter list" in MissionPlanner you will see lots of parameters starting with SONAR. Here is the current list:
- SONAR_DEBOUNCE
- SONAR_ENABLE
- SONAR_FUNCTION
- SONAR_MAX_CM
- SONAR_MIN_CM
- SONAR_OFFSET
- SONAR_PIN
- SONAR_SCALING
- SONAR_TRIGGER_CM
- SONAR_TURN_ANGLE
- SONAR_TURN_TIME
- SONAR2_ENABLE
- SONAR2_FUNCTION
- SONAR2_MAX_CM
- SONAR2_MIN_CM
- SONAR2_OFFSET
- SONAR2_PIN
- SONAR2_SCALING
That is quite a lot of parameters to play with! You can enable 0, 1 or 2 sonars. Each sonar can be of a different type, with a different mapping function between voltage and range. You can choose what analog pin each sonar is connected to. You can also choose the turn angle that the obstacle avoidance code will use when it detects an object, how long it will turn for, and how much debouncing it will do on the sonar signal.
To help you debug all these new sonar parameters, we have a new driving mode, called STEERING mode.
Steering Mode
Steering mode is a bit like learning mode, except that the controls use the same steering, throttle and obstacle avoidance code as AUTO mode does. The steering controls the "navigation bearing", which is what AUTO uses to navigate. The throttle controls the target speed, just like AUTO does. When it sees an obstacle it tries to avoid it in the same way that AUTO does. It even does turn speed scaling.
So you can use STEERING mode to test your rover while remaining fully in control. Drive it at a obstacle, and it will avoid it, which is not only fun, it's great for tuning.
New Failsafe Code
The new failsafe code gives you much more control over what happens when you go out of RC range, or you lost contact with the ground station. The key parameters are:
- FS_ACTION
- FS_GCS_ENABLE
- FS_THR_ENABLE
- FS_THR_VALUE
- FS_TIMEOUT
The FS_ACTION parameters tells APM what to do when a failsafe triggers. You have 3 choices - do nothing, start an RTL or hold position (there is a new driving mode called 'HOLD' to support that last option). The other options control what triggers a failsafe, and how long the failsafe condition has to happen for before it triggers.
New Auto Start options
Have you ever wanted to kick your rover? Now you have an excuse. There is a new AUTO_KICKSTART option which tells the APM not to start the motor in AUTO until it sees an X acceleration of a specific number of m/s/s. So put your rover on the start line, flick it to AUTO then give it a kick to start it going. Don't kick too hard :-)
There is also a AUTO_TRIGGER_PIN option that allows you to set an input pin that can be used for a more gentle AUTO start. Attach a switch which shorts that pin to ground and you have yourself a start button for AUTO.
Speed Scaling
To drive a course at high speed you need to slow down in turns, unless your rover is on rails. To support higher speeds the new rover code now supports options to control when to slow down.
- SPEED_TURN_DIST
- SPEED_TURN_GAIN
The distance is how soon before a waypoint the rover starts to slow. Watch out for GPS lag!
The turn gain is how much it drops the throttle when approaching a waypoint or turning. If you have a low center of gravity this can be close to 100%, but if your rover tends to tip easily then set it much lower.
That should be enough to get you started. Happy Rovering!
Cheers, Tridge
Replies
Guys this is going to sound really lame, but how do I save the .hex file in the beta folder from the link provided above? If I right click on the link and choose 'Save Taget As', it saves it as .htm. Is this as simple as changing the file extension to .hex?
I don't know about 2.40, but I had compiled and loaded 2.30, and then tried to install and run a 3DR 900 MHz radio. The radios would connect (both solid green), and I thought I could even see the heartbeat (1 sec rate) flash on the sending and receiving LEDs. Luckily it dawned on me that I had a beta version, so I re-loaded the 2.2b. Radio works now.
Any news on 2.30 or 2.40 working with the 3DR's ?
Alan KM6VV
Great improvements on obstacle avoidance.
Looking to set up my brushless Stampede as an ArduRover.
Has anybody looked at a servo scanned tight beam SONAR like one of the Maxbotix narrow beam horn types for instance?
Like this: http://www.maxbotix.com/Ultrasonic_Sensors/MB7386.htm
That sounds great!
I'm looking forward to this release. Turn in place for skid-steer might be a problem for my 6WD, but that can be resolved. I like the dual sonar mode, although I'm thinking of even using three SRF08 sonars. These need I2C. Start mode is appreciated as well as the hold mode. We need a way to "visit" a cone in a waypoint, then continue on to the goal. Actually, I think we need to touch the cone lightly (contact switch) and then pull away and continue.
I would like to ask for an output pin for "in waypoint" circle. I am looking into that myself. This pin would allow switching of behaviors between obstacle avoidance and "target" tracking by an outside module. This outside module will use my three sonar inputs, and a camera input as well as the throttle and steering inputs. Other option when APM obstacle tracking is fully developed would be to read a "camera steering" servo signal from the tracking camera. This tracking camera would be driven from a "blob detection" processor. At least, that's my theory.
Question: does obstacle tracking do a "back-off and turn" when it gets too close to an obstacle? Or just "drive around" at this time?
Alan KM6VV
Congratulations to the ArduRover2 code hacking team and especially to Tridge who put together the comprehensive usage instructions above. Now, let's get this beta version rung out so that we can be assured of consistent rover operation with no surprises!
Regards,
TCIII Admin