Copter
General
Issues
Attendee count (max): 22
09:02am - 3.8 parameters airspeed
The auto-upgrade of the parameters is not great
In particular, analogue sensors won’t copy across
Analogue airspeed sensors really, really should not be used!
No way to detect errors
09:04am - Randy and Copter
Rc7 was pushed out last Thursday
Resolved a bunch or problems
RPi NavIO board
ESC calibration
Sport mode not resetting
Others
Some outstanding issues
Randy’s got about 25 support messages to respond to
Don says mission-clear-all fails half the time
Not a new issue
09:05am - tridge and DSM
PixRacer with Spektrum satellite isn’t binding
PixRacer DSM issues on higher channels
Need to capture the raw stream from the receiver and run it through the decoder
DSM implementation as stand-alone program in the source tree
You can run the program against the receiver on a FTDI cable
You can get someone else to proxy a receiver for you
DSM vs DSMX
Number channel
Timing (11 and 22ms)
4 different protocols
ArduPilot sees the same bytes
Binding can’t be done remotely
Power pin on receiver has to be toggled
Power pin is software-controllable
Should we support these OrangeRX?
Yes, many, many people use them
Spektrum + OrangeRX
Problems aren’t just on the OrangeRX side
Spektrum tweak the protocol to make it incompatible with other manufacturer’s receivers
Pointless changes in the timing just to annoy other receivers
OrangeRX tend to be quite forgiving in what they talk to
Do we need to distinguish between the two in software?
Shouldn’t need to
OrangeRX seem to be OK in terms of just-working
09:17am - back to Randy and Copter again
Turning to next waypoint
Changed the way we point in 3.5
Now doesn’t turn too early
Will fly sideways on occasion…
More patches to come on this
Yaw control with coax copter in SITL seems odd
Nobody on dev team as a single or coax copter
Randy is not convinced we fly these things well at all
Dodecahexa support added
Need to get a diagram for it to go on the Wiki
M Levine might be able to help out here
He did the ArduSub logo for us recently
Motor ordering is simply clockwise (front top/front bottom, …)
Someone is going to be converting a hexa to a dodecahexa
09:22am - Wiki stuff with Randy
Modifying menus isn’t working
Not getting rebuilt
Buzz or Jani or tridge needed?
Need a page on “getting started with development”
Need some work on the log analysis pages
Randy would appreciate any and all help he can get on the wiki
09:23am - Randy and Japan Innovation Challenge
Kick-off event was yesterday
Explained rules
Haven’t nailed all the rules down
Some problems specific to Japan
Telemetry
Must be legal
Which means crappy
XBees!
DJI have certified
1 or 2km range from DJI gear
Need to decide on CC and camera and gimbal
TX1 with a RPi2 camera?
Want to go to UV
Shows up clothing really well
3kmx1km elipse
Huge area notionally
But the bodies were all in a line along the trail last year
Which is why people playing with FPV could do it so easily last time
Randy suggested they need to make it harder
Fairly large team required
Lots of roles
Package delivery
Telemetry
camera /gimbal
Image recognition
…
09:33am - tridge
arbitrary motor periods for brushed motors
RC_SPEED parameter
Need brushed motor vehicle videos on wiki!
Dual-motor tailsitters
Mark W
https://github.com/ArduPilot/ardupilot/pull/6282
Non-vectored tailsitters
AP_Motors doesn’t have attitude error atm
Calculated at attitude controller
Boost throttle to correct attitude error might need this data
Might need to pass attitude error down into motors library
This is a significant layering issue
Vectored tailsitter
When taking off
Laying belly-on-ground with motors off
Without change
Motors build up integrator and point up a little bit
Not enough
They need to be straight up
To know they have to point straight up it needs to know the attitude error
Or the PID gains would have to be huge
Which would make it unstable once flying
Need a continuous change
A rate controller
Leonard suggested feed-forward on attitude error?
Tridge put this in the quadplane code
Motors library gives its normal outputs
Then quadplane code modifies it based on pitch error
Pretty hacky
Motors library should be able to do this itself
Rates are typically quite low
Mark could do the same thing as tridge did here
https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/tailsitter.cpp#L65
But we should probably pass through an angle error
Is the angle-error general enough?
Probably
Tailsitters!
Constrained areas
Interesting things with them
Banggood thing coming
https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/tailsitter.cpp#L65
https://www.banggood.com/VTOL-Vertical-Take-off-And-Landing-Sport-3D-PP-RC-Airplane-Aircraft-KIT-p-1137084.html?rmmds=detail-left-hotproducts
10:00am - dropping NMEA as an auto-configured GPS type
Usually a problem where autoconfig fails
E.g. dud TX line to GPS
So stop auto-detecting NMEA
Worst driver to use
Still allow configuration
Should we get rid of AUTO entirely?!
Default to uBlox and let people change it if they want to
PR from Paul:
https://github.com/ArduPilot/ardupilot/pull/6315
Reduce startup delays in EKF
Need to take a worst-case assumption for GPS
EKF only starts after GPS is detected
GPS type 2?
Not present then EKF won’t start!
What about dual GPS?
If you mis-specify on GPS_TYPE2 then you similarly won’t start
Patch is also about memory performance
But we’re really not short on memory right now
But also reducing buffer size for performance reasons
Reduction in fusion horizon
More accurate predictions
Could we dynamically adjust the fusion horizon based on GPS lag?
Paul had a couple of objections to this
How do you shorten the buffer?
Don’t want to throw data away
Should probably put this in as it is an improvement
Later we could look at shortening buffers
Maybe one-sample-at-a-time
Are we assuming a constant lag here which may not be true?
Have a parameter which sets the upper limit on the timing delay
10:13am - issues list
https://github.com/ArduPilot/ardupilot/issues/6306
GCS interface issue allowed it to happen in the first time
There’s a confirmation now for mode change though
Plane will change to manual even under RC failsafe via mavlink
Rc overrides?
Stop servos straining/chattering on bench
Could base it on armed vs disarmed?
Plane has different philosophy vs Copter
Always change mode
Without checking
Then cope as best you can
If pilot tells the vehicle to do something, it should do it
If you are in rc failsafe then we should ignore the mode channel
We already do that
https://github.com/ardupilot/ardupilot/blob/master/ArduPlane/control_modes.cpp#L12
https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/GCS_Mavlink.cpp#L848
Are we using manual for what it is intended?
Or do we need something which neutralizes all channels?
Mode initializing?
Training, acro and manual are all not attitude-stabilized
No rc input in these modes are problems
FBW and CRUISE are attitude stabilized
Sometimes putting the vehicle into manual is actual the preferable thing to do
So you can deliberately crash the aircraft
That’s a fundamental different between manned vs rc
Sometimes crashing is the Right Thing To Do
Users should prepare better
Fences
Do-land-starts
Do we need a panic button for the GCS?
Would need a confirmation….
Conclusion:
Make sure GCS confirm mode changes that require RC input if you’re currently in RC failsafe
https://github.com/ArduPilot/ardupilot/issues/747
Send MAVLINK_MSG_ID_GPS_GLOBAL_ORIGIN
HOME_POSITION has replaced the need for sending this message
https://github.com/ArduPilot/ardupilot/pull/6341
Continuously send out commands indicating success/failure to GCS
1-second interval
Like we do for mag
Mavproxy should stop using statustext monitoring
10:40am - Mastering Solo with Matt
Two big things
Solex developer (Kelly) for Android created ability to load firmware and Python to Solo!
One-click process
Several reports of success already
Last bit required before special Solo builds are required:
Big change is to do notification devices dynamically
Switch to turn OreoLEDs on or off
Rover mode or aircraft mode
Dumped special tones
New power-off tone
Notify_brd_type parameter issue?
Why not use the existing brd_type parameter/
Distinguish between px4-v3 and Solo?
Perhaps we should add a new brd_type for Solo?
The notify_brd_types don’t match up with hardware configuration
So just use the BRD_TYPE
And keep the OLED theme (which acts as an enable as well)
Slew rate?
Hugh Eaves has something that works?
Not considered “critical” for Solo work on master
Would be great to have for 3.5.1
Don’t want to hold up the production release of master-on-Solo
Need to reduce use of inline keyword
10:59am - anything off the floor?
Nope!