Hi everyone. The ardupilot team is delighted to announce the release of version 2.48 of APM:Rover.
In case anyone needs to manually download the beta release its here - http://firmware.diydrones.com/Rover/stable/
This is a picture of the rover Tridge used when he was doing some differential GPS work.
Release 2.48, February 20th 2015
--------------------------------------------
The ardupilot development team has released version 2.48 of
APM:Rover. This release is a bug fix release with some important bugs
found by the users of ardupilot.
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
- Auto formatting of SDCard if it cannot be accessed on startup
- A number of significant performance improvements for the PX4 platform
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 minimum 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.
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 to 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.
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.
APM:Rover. This release is a bug fix release with some important bugs
found by the users of ardupilot.
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
- Auto formatting of SDCard if it cannot be accessed on startup
- A number of significant performance improvements for the PX4 platform
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 minimum 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.
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 to 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.
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.
Replies
Hi Grant,
Thank you for all your efforts. I'm wondering if anyone is working on driving a rover waypoint to waypoint backwards?
Thanks again
RoboBill
Hi RoboBill. Hmmm, a rover driving backward between waypoints. We have partial reverse support but only in steering mode. But it doesn't have a reverse in auto. It could be done. What is your trying to do that you need to go backwards between waypoints - I'm just curious ;-)
Thanks, Grant.
Hi Grant,
I'm more than happy to attempt to satisfy your curiosity. My 4' wide rover needs to backup in two phases of its mission. The first is it needs to simply back out from its charging station. The second part of its mission (of a minimum of 80+ waypoints) is a very laborious back and forth sweeping like motion of 50 feet between waypoints. To turn 180 degrees takes much more time and battery power.
Thanks,
RoboBill
Charging station. Wow, sounds cool. I'd love to see some photo's of your rover and any more detailed info if you can/are allowed to provide it.
I'll have a look into adding reverse in all modes. On the face of it it shouldn't be that hard.
Thanks, Grant.
My rover is at AutoCourtDryer.com.
I'd also appreciate your thoughts about alternatives to the Pixhawk GPS guidance system. On the surface, the Pixhawk/GPS/Mission Planner system is very simple and user friendly. But GPS' must have good sky views. That's OK for a copter in the sky, but kinda tough for ground vehicles that have many objects around it to worry about. Plus GPS' are only good to +/- 3 meters. I'm trying to help find an alternative to GPS' while helping rovers "see" better for both indoors and outside environments. I'd appreciate your thoughts as to how difficult it would be to incorporate my rotating laser described here to find waypoints? Or should I bite the bullet and submit to the overwhelming complexities of ROS?
Thanks
RoboBill
Great product idea! I'm gunna see if I can get the reverse mode into rover in the next few days.
I feel you pain on accuracy. Its not something plane and copter have to worry about too much. So I flew a couple of meters off - there is nothing in the air to hit!! I too am keen to find a way to nut this for rover.
Rotating lasers are a good idea but complex - well for me anyway. I reckon its fantastic that you are having a crack at it and I love your design. It would be awesome if it works.
How are you thinking the rotating laser would find waypoints? I can see it doing obstacle avoidance but not sure how it would handle navigation. Somehow it would need to know it headed NorthEast 2 meters in the same way GPS knows it - can it do that? Can it somehow figure out its direction and speed from the changing light map? See - told you it was complex for me ;-)
I have got my hands on some Swift Navigation Piksi's. These are RTK GPS but they are fully open source and I really like that. They are sitting here in a box in front of me begging me to play with them - just need some time. Obviously this is only an outside solution but if I can get cm accuracy out of these that will be great. Not cheap but great. I will definitely let everyone here know how I go.
The other thought I've had is an optical flow sensor for navigation. Its basically like an optical mouse. I had a very brief exchange with our resident math guru and optical flow sensor guy Paul Riseborough and it went like this:
Grant Morphett: Hi Paul. Regarding the optflow sensor - is there a minimum height at which it will work? I ask as I was toying with the idea of attaching one to a rover and writing some software to enable it to do indoor navigation
Paul Riseborough: Assuming the lens has the focal adjustment, it comes down to a function of height above ground, the focal length of the lens and the maximum ground speed. With the default 16mm lens fitted, the maximum velocity that can be handled reliably is approximately 2.5xheight, so if you were 30 cm above ground it would measure up to 75 cm/sec (max flow rate of 3 rad/sec). The following link gives an indication of the maximum velocity that can be handled as a function of height and lens focal length.
https://pixhawk.org/modules/px4flow
Again, more time required - a lot more time :-)
Thanks, Grant!
Has there been any update on reverse? I'm building a skid steer rover where I'd like it to navigate to a waypoint in forward, then the next in reverse. I'm considering mounting the APM on a servo, and connecting relays into the motor wires, where when I hit the waypoint, it will flip the APM 180 and reverse the motor inputs, but there must be a better way. Perhaps a DO-SET-PARAMETER mission command can be added? I could see uses for that across all the APM modes.
Good morning Grant,
My initial thoughts for integration of the scanner into the Pixhawk would be as an assistant or back up to the GPS. When the GPS lost lock, the scanner mapping program would take over and guide the rover to the next waypoint(s) until GPS relocked. The scanner would also help the Pixhawk drive around obstacles.
Yea I realize that's a huge task but my hope is that more people will be able to build their own scanner and come up with an innovative way to make this all happen.
And yes I have the Piski too, but they seem to be in a very youthful beta.
And hooking up a PX4 as an optical mouse would be interesting... definitely for indoor use, but I wonder what effects a wet ground surface will have on the "mouse" optics.
Thanks for listening to my thoughts?
RoboBill
@Grant,
Based on my dual GPS testing last year with my Slash Rover, the loss of GPS lock out in the open was so momentary, based on analysis of the data flash logs, that I doubt that there will be much benefit from a scanner out in the open.
However, around tall buildings or large trees it may come in handy when the HDOP increases above 2.0 or GPS lock is lost for a significant period of time.
Regards,
Tom C AVD
Thank You.
Regards,
David R. Boulanger
-
1
-
2
of 2 Next