Issues & Pull Requests
- Release Update
- Release Update
- Release Update
Issues & Pull Requests
Can we add https://github.com/ArduPilot/pymavlink/pull/234
to the call please
Attendee count (max): 24
Tridge and fr-sky pass-through code
How well does it work?
30 seconds to a minute?
Luis sees 1 second-ish
“Shouldn’t be working”
Maybe the receiver?
Maybe the binding?
MdB not present
FF is going to review it quickly
Revisit later in the call
Looks good to FF
Distance to waypoints and things
Need to make stuff generically available
Stop getting stuff from vehicle directories
Randy doesn’t want Notify to be used as an information bus
Tridge wants a structure somewhere where we just add fields to which the vehicle code writes to
Peter suggests it should go into GCS
How do singletons affect this?
How about AP_Vehicle?
Make it a singleton?
Put the structure in there?
Think of it like a “blackboard”
No inherited vehicle class at this point!
Put this PR off until we have an AP_Vehicle singleton and converted OSD over to it
Tridge to work with Alex on existing frsky code
Randy would like this merged as he’s looking at supporting
UTC2328 - crow breaks
Tridge has gotten through some of the ones with his name on it
But not this one!
FF has been using it all the time
Anything that did work should work
Tridge is thinking of doing CI on AppVeyor
UTC2341 - random Plane PRs
Need do read/write
ABI guarantees no field reordering
Some computers don’t do 32-bit integers!
Locking of home
Mission Planner and setting of home….
Make mission at home, go to field
MissionPlanner asks if you want to set home
What does this actually do?
Mission Planner has own “home”
MP only sets vehicle home if you right-click and say set-home
Locking barometric vertical home is the issue
Missing MdB and Nate to discuss this one
Sid is going to try to get to the bottom of these issues
Some related PRs
Worse with GPSs not doing 5Hz
Will ping MdB on this one
UTC0008 - autotuning yaw
TECS tuning would be a higher priority
Tridge and Tom will discuss
[11:15 AM] (Channel) TomPittenger: FYI, here’s the TECS autotune issue
Constant learning instead of a tuning mode?
Adaptive controller stuff?
Promising but needs to be fixed end-user-experience-wise
another MdB thing!
Recent feature: When doing mission based landing do a fixed wing landing until facing into wind at appropriate altitude
Automatically using q-trans should be the default
No MdB to discuss with, so moving on
Adding support with with-wip
Lots of work being done in upstream mavlink
Lots of stuff marked as WIP
This PR adds supports so that WIP messages are stripped from documentation and generationed code
Reduces distance between forks
Can bring WIP messages in from upstream and they won’t appear
We already have wip messages…
Pymavlink releases won’t get any WIP messages
Won’t be able to mavlogdump logs…
What’s the point of WIP?
WIP markup is fine
Would be nice if you used a WIP message you got a warning when compiling
What does this gain us?
Say you’re adding a new feature, a new WIP camera message
Would like users to be able to try new message
Users using pre-built mavexplorer or mavlogdump or qgc or whatever
They want to be able to see those messages?
What’s the downside of always generating the WIP messages?
This means stable releases are stable
how about, instead:
Generate wip messages but first time you use it it warns you are using a WIP message
Could have a define saying no-wip-messages
Maybe just a warning during build?
Trying to prevent a WIP message getting into a stable release?
Choose something from https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html ?
Maybe the “warning” message attribute
UTC0038 - Plane 3.9 point release
Fixed bug in RC channels
3.10 series will start soon based on master
UCT0039 - Copter update
Several enhancements into the next point release (3.6.1)
Relative vs absolute devop
A few new boards supported
Battery failsafe voltage parameter conversion fix
Several issues still to address
Breakout cable for microsd would be really handy
Tridge’s mindpx doesn’t log at all
Tridge is thinking really low level problem here
Length of traces and the like
Drain resistor presence and size
Scope of problem?
Reminds people of an old PX4v1 bug where the debug cable would cause the SD card to not work
NuttX instead of ChibiOS on boards where it is a problem?
SD card implementation guides are massive
EMI suppression register?
Probably the most serious issue we have outstanding
12m offset in some LIDARs
Benewake tf-mini issues
Reporting unhealthy when out of range
Already have a fix for this
Just a documentation issue, user needs to fix parameters
D-shot on iomcu should be possible…
UTC0059 - 3.5.0rc1 has gone out for Rover
Live calibration is awesome
Hopefully out within a month
UTC0101 - marketing update
Last Wed team had a relatively long call to figure out some marketing matters
Pushing social media stuff
Discussed tradeshow plans
Discussed regulatory interfacing
Content issues on Wiki
Talking with augmented reality people that overlays street names and the like over live video streams
Was looking for a one or two link thing to pass onto them
They currently do DJI API
Maybe we could implement that interface?
Tridge is kind of interested
Significant lump of work
Subset of API
Lots of bits that are probably unused
Jeff will follow up
UTC0110 - CI
Plagued with failing CI tests
Fails in CI but not locally?
Tridge has pushed a feature into master which allows us to get logs from failed travis tests
Should be able to narrow the causes down
Lots of logs due to rebooting
Peter is looking at renaming the dataflash log files to be more useful
80% packet loss on Rover?
UTC0116 - high packet loss
Could be sequencing
Use mavlogdump to show the sequence numbers
Could be mavlink system IDs
Pixhawk connected to companion computer via serial link
WiFi or wired it doesn’t matter
Mavproxy doesn’t show packet loss
Qgc doesn’t see it
Qgc is 252
UTC01120 - vote on bugmaster thing!