- AC3.5 release - should have gone out today but build server didn’t update. it probably will tomorrow on it’s own.
- Updates (wheel encoders, architecture)
- 3.8 testing
Issues & PRs
Issues & PRs
Attendee count (max): 28
09:02am - Randy and Copter
3.5 is going out today!
Was supposed to be yesterday
Matt reports it is out on the firmware server folders
Downloaded, installed and flying on Solo
ONLY SAFE with GREEN CUBE or similar mods!
PR in place for throttle limiting
There’s a lot of happiness in the Solo community that their vehicles are shown to be alive-and-kicking
But the build server didn’t push it out
No changes since -rc11
EKF and DF issues were found in master but were not present on Copter branch
Marco might be doing a video for it
09:10am - Randy and Rover
Wheel encoders have been added in
Paul hopes to work on integration to EKF this week
Brushed motor support
Motor test feature coming
“Flight modes” patch should be coming in
09:16am - tridge and Plane
Couple of bugs found in 3.8
Dataflash download issue
Peter is looking at this
Motor start on reboot
PX4-mixer changes caused this
Fix is in place
Need to replace the mixing
Manual RC mask is going out which permits deep-stall
Testing needed on reverse-thrust plane
Probe ordering has changed as CANBUS is now done first
internal/external and orientation were all wrong
As well as the IDs
Historically we’ve put external i2c first
This change was supposed to put external CANBUS compasses first too
CANBUS is slow to start
Detection can be intermittent
Ignoring warnings could easily lead to a crash
Hot-plug support would work here
Currently we only hot-plug GPS
MdB “Don’t do it! It’s a world of headaches!”
Could switch primaries based on IDs when we see them
We do sleep 5 seconds to let CANBUS enumerate
This change also puts CANBUS compasses in front of the i2c compasses
Also means you get canbus compass in your list of compasses if you have many compasses
Some crash reports of 3.8beta5
Got through these
Actual reports were caused by reversed servos
But FBWA was reversed
Need to emphasise that you MUST check the automatic upgrade to 3.8!
Preflight checks are really, really important
Rover RC calibration / Mission Planner; reversing channels does odd things
MissionPlanner is going to work hard 3.7 vs 3.8 as the servo changes mean things work very differently
Perhaps it shouldn’t update the servo reversal when doing RC cal?
But need a separate screen for servo reversal
The servo/rc split gives us a vast amount of flexibility
But does add complexity
GCS need to do a lot of work
Maybe wizards would be appropriate?
A lot of documentation is going to be written for 3.8 to try to cover this
Deepstall PIDs have moved!
Anybody moving through the 3.8 release series should check their PIDs each upgrade!
Tom and quadplane disarm/rearm
Should honour disarm-on-landing parameter
But this won’t fix the actual issue!
Need something that allows you to move onto next mission item
Why do we disarm immediately?
Because holding position on the ground is not good
Shifting GPS positions might flip you over
Could add the shifting-target stuff if vehicle thinks it is landed
Disarming sooner with disarm_delay was to stop plane thrashing motor on ground
This would remove that
Disarming quadplanes later
When on ground it is spinning motors on ground (at min throttle level)
Why would you want to delay the disarm?
If you land fixed-wing it already honours disarm delay
We could support multi-part missions into the future
A mission item for GPIO reading might be doable
Python scripts supervising things are a valid option!
But more possibilities of bugs!
Balloon-popper hybrid mode
also == package delivery mission item?
MdB: Flash tradeoff on that, if its a competition only item I’m not sure it really belongs in master (unless hidden with a #ifdef but that way lides code rot), if it has wider utility then absolute
Big assumption that if you’re disarmed then missions aren’t running
10:15am - issues
Change to allow NaNs in dataflash logs
This will go in
Peter will check QGroundControl is happy
MAVExplorer is OK with it
10:21am - Sebastian and smart rtl
Resource intensive algorithm is happening in the IO thread
Same place as sd card
Small state machine
1ms at a time
Background thread only looks at memory
Keeps a bitmask of the point that should be deleted
More work to do for thread safety
More RAM for stack space is pretty much the only cost
Threads we currently run
Used to be used for sensor reading but we now use bus threads
Nothing flown yet
A lot of simulation
Parameter for resolution?
Being able to run smart-RTL in either place would be awesome
Writing optimised points to SD card?
Want to handle GPS glitching!
Position_ok() function in Copter
Helper functions: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Math/location.cpp#L301
10:39am - Siriam’s project
Complicated hardware aspect
External dependencies on HW engineers
Payload weight sensor
Might not be ready for the project
Could use simulator?
Has access to flight simulator now
Andoid phone plugs into USB on PixHawk
Relays telemetry over 2G/3G
Already done? http://andruav.com/
Not open source
Whole phone is the companion computer concept?
Replace payload-weight-sensor project with something else?
Android phone software?
Or trying to use software solution to emulate the same sensing (rotor speed control?)
Meeting to be scheduled to sort this out
10:56am - Amilcar
Lots of stuff working in terms of infrastructure on Windows
Anybody else working on this - it would be nice to collaborate
Low-altitude fence for Copter is working
Rover is losing high-alt and low-alt fence
Plane is going to be hard
Rover is going to be relatively easy
Randy is interested in SLAM again!
11:06am - Philip and hardware
1.4 uBlox firmware
Moving baseline vs fixed moving baseline
For follow-me and precision landing and the like
Can’t get heading out
Maybe for firmware 1.5
This one just gives you an accurate distance and vector from the base station when the base station is moving but doesn’t give you a better absolute position than a normal GPS
Amilcar has a PR in to do with moving baseline which he’d like looked at (MdB!)
Aids in precision landing and the like
Follow-up PR requires emLid firmware changes so we should wait for that to become stable
But that makes the first one a no-op
Don’t want dead code in the tree
Drivers which use it will be coming soon
Adds support for feature on 3 GPS
No dead code in this one!
Paul is in favour