Hi everyone. We have just released version 2.48beta1 of APM:Rover.
This is a picture of a Maxstone 10 rock crawler - or in this case dining room table crawler. Its been built by TradHeli expert and ArduPilot developer Robert Lefebvre. He's a secret Rover fan ;-)
We would really appreciate some test reports with this version. We hope to do the release next week.
In case anyone needs to manually download the beta release its here - http://firmware.diydrones.com/Rover/beta/
The changes in this release are:
- fixed a bug that could cause short term loss of RC control with
some receiver systems and configurations
- allowed for shorter sync pulse widths for PPM-SUM receivers on
APM1 and APM2
- fix an issue where battery reporting could be intermittent (thanks
Georgii Staroselskii!)
- fixed a mission handling bug that could cause a crash if jump
commands form an infinite loop (thanks to Dellarb for reporting
this bug)
- improved support for in-kernel SPI handling on Linux (thanks to John Williams)
- support UAVCAN based ESCs and GPS modules on Pixhawk (thanks to
Pavel, Holger and and PX4 dev team)
- Multiple updates for the NavIO+ cape on RaspberryPi (thanks to
Emlid)
- Lots of EKF changes
- added support for MAVLink packet routing
- added detection and recovery from faulty gyro and accel sensors
- added support for BBBMini Linux port
- increased number of AVR input channels from 8 to 11
- auto-set system clock based on GPS in Linux ports
- added SBUS FrSky telemetry support (thanks to Mathias)
- Added AK8963 MAG support (thanks Staroselskii Georgii)
- Added support for second battery
The most important bug fix is the one for short term loss of RC
control. This is a very long standing bug which didn't have a
noticible impact for most people, but could cause loss of RC control
for around 1 or 2 seconds for some people in certain circumstances.
The bug was in the the AP_HAL RCInput API. Each HAL backend has a flag
that says whether there is a new RC input frame available. That flag
was cleared by the read() method (typically hal.rcin->read()). Callers
would check for new input by checking the boolean
hal.rcin->new_input() function.
The problem was that read() was called from multiple places. Normally
this is fine as reads from other than the main radio input loop happen
before the other reads, but if the timing of the new radio frame
exactly matched the loop frequency then a read from another place
could clear the new_input flag and we would not see the new RC input
frame. If that happened enough times we would go into a short term RC
failsafe and ignore RC inputs, even in manual mode.
The fix was very simple - it is the new_input() function itself that
should clear the flag, not read().
Many thanks to MarkM for helping us track down this bug by providing
us with sufficient detail on how to reproduce it. In Marks case his
OpenLRSng configuration happened to produce exactly the worst case
timing needed to reproduce the issue. Once Tridge copied his OpenLRS
settings to his TX/RX he was able to reproduce the problem and it was
easy to find and fix.
A number of users have reported occasional glitches in manual control
where servos pause for short periods in past releases. It is likely
that some of those issues were caused by this bug. The dev team would
like to apologise for taking so long to track down this bug!
The other main change was also related to RC input. Some receivers use
a PPM-SUM sync pulse width shorter than what the APM1/APM2 code was
setup to handle. The OpenLRSng default sync pulse width is 3000
microseconds, but the APM1/APM2 code was written for a mininum sync
pulse width of 4000 microseconds. For this release we have changed the
APM1/APM2 driver to accept a sync pulse width down to 2700
microseconds.
Replies
Today the weather was fine enough to make a test run with my rover. I used the latest version of software and have some concerns. Sorry for my English.
The rover is built for Skid Steering. I use Graupner Speed Profi 40R, one per side.
1 The rover will not start after arming. If I lift it and turn it it will start and then run the mission. MP says Auto and Armed.
2. The motors never reverse. It may be my fault but I cannot find it. They do if I connect them to the receiver.
3. When RTL is finished the rover continues to run at about 50% power endlessly. Without navigation.
Hi Anders. Are you still having issues? If you search the forums for skid steering there is quite a lot of information.
Let us know.
Thanks, Grant
Hi Grant,
Nice job in correcting a number of issues and bug reports.
I will have to give it a try as soon as the weather gets better here in Southern Florida.
Regards,
TCIII AVD
Tridge has reminded me of a recent feature he has added to ArduPilot that I should of mentioned (I’ll include it in the release notes).
Auto format of SD Card
From time to time the SD cards in the PX4 autopilots get corrupted. This isn't a surprise considering what we do to them. Your all familiar with the windows "please unmount or eject your SDCard before removing" process. Well we don't do that. In fact normal operation is to just pull the power on the SDCard - whilst its being written too!! Not to mention the horrible vibration rich environment the SDCard exists in.
If the autopilot is setup in the internal innards of your plane/copter/rover this can be a nightmare to get to. To resolve that problem Tridge has added code at startup so when ArduPilot tries to mount the SDCard to access it - if that fails it will then try to format the SDCard and if successful mount the card and proceed. If the format fails then you will get the usual SOS Audio that makes most of us want to find the buzzer and rip its heart out.
I mention this in case anyone has precious logs saved on the SDCard or they are using the SDCard out of their phone with their wedding photo's on it. Probably best not to do that and assume any data on the SDCard can be deleted at any time.
We are also looking to add a parameter to control whether the card is auto formatted on startup or not but it isn't in there yet.
Thanks, Grant.
Bravo! I'll be testing this weekend.