Attendee count (max): 19
UTC1100 - Welcome new people!
- Ryan (Rhino) and James O (Joshanne)
- Both ArduPilot devs and interested in seeing what happens at these calls!
UTC1101 - https://github.com/ArduPilot/ardupilot/pull/14892
- Able to access REPL over a serial link
- Type LUA code in and have it executed directly
- No MdB
- Very response as opposed to over-mavlink
- Need a MAVProxy thing for REPL-over-mavlink
- Need to get MdB’s approval
- Can be merged after MdB says it is OK
UTC1104 - https://github.com/ArduPilot/ardupilot/pull/15065
- Perhaps we do this properly and get told how many extensions are actually present?
- Given pointer to mavlink_message_t and an offset into the structure, indicate whether this value as filled in
- Does mavlink_message_t already have the wire length?
- Decoded structure doesn’t have that information
- Add booleans into structure?
- Least intrusive is probably a boolean function takin the mavlink_message_t
UTC1117 - https://github.com/ArduPilot/ardupilot/pull/15064/files
- Can be merged after the indenting fail is fixed
- Move the cast into where the default define is used
UTC1120 - https://github.com/ArduPilot/ardupilot/issues/15028
- Generally PRs need more description in them
- Use fail radius + twice the loiter radius?
- More work required
UTC1135 - https://github.com/ArduPilot/ardupilot/pull/15062/files
- we ‘d lose all warning to the user that mode change had failed
- Should make sure other mode change efforts similarly fail
UTC1141 - https://github.com/ArduPilot/ardupilot/pull/15041
- Recent changes have made DSM too lenient so it is detected when it shouldn’t
- The specification is absolute garbage
- Doesn’t work on genuine gear, let along knockoff gear
- Adds RC protocols options so you can specify which protocols you want to be able to decode
- Vast numbers of ways we get RC input
- Will need a lot of testing, and volunteers would be really good
UTC1147 - https://github.com/ArduPilot/ardupilot/pull/15032
- Minimum PWM to honour on the start channel
- RC option switch won’t allow bands of allowable PWM values
- RC channel min?
- Existing setups people may not be able to stop the motor
- Key safety feature would be disabled
- Using new parameter makes it opt-in
- In the particular case there was no RC failsafe
- Ppm doesn’t have any way to transmit it except via throttle channel
- Rfd900x firmware is really difficult to get working correctly in case of RC loss, and very hard to test
- Failsafe throttle value was below 1000 so the throttle level dropped
- Throttle failsafe was also disabled
- There’s already a throttle-failsafe==2 option
- Spektrum transmitter
- Rfd900x ppm pass-through
- Spektrum -> spektrum receiver --ppm–> rfd900x -> rfd900x --ppm–> autopilot
- Issue with all kinds of input from pilot
- roll/pitch/yaw all mixed up?
- If in auto and no stick-mixing, not a problem
- throttle-failsafe==2 help here
- Could have a new RC channel option instead of a new parameter
- One of the three positions has to be a band
- Record current PWM as the failsafe values
- No equivalent for reading the values
- Can’t specify explicitly
- To test it you have to depower the ground radio so you can’t see the values
- These radios are out and being widely used
- Deal with the reality of a bad piece of hardware
- This is still probably the best of what’s out there
- There are firmware fixes that work
- 3.x firmwares have half the bandwidth of the 2.x releases
- Manufacturer is aware
- 2 or 3 Mbit changes halve the available bandwidth on low bandwidth
- Manufacturer doesn’t want to fix it
- Tridge is considering offering a patch against the 2.x firmwares
- Rfd900x firmware needs a lot of work to be of quality sufficient for the applications it is now being applied to
- Really, really difficult to test
- Engine has to be running
- … so using USB to test is problematic
- RCOU logging doesn’t log last two channels
- Randy’s not going to block this as Copter doesn’t use ICE
- But does object to the way the situation is being handled
- How long do we have to carry this “fix”?
- Tridge is taking responsibility for this change
UTC0005 - https://github.com/ArduPilot/ardupilot/pull/15010
- Motors library from LUA
- Works and is tested
- Set-output-norm does honour the channel reversal
- Comments have been corrected
- Same approach for Copter will be a little problematic
- Perhaps we ought to fix get_output_norm
- Want to get this merged before end of GSoC period
- Rename old one and create a fixed one
- Don’t want to ensconce poor semantics
- Not using output_scaled; at function level as opposed to the others which are servo-level
- Will merge it after a bit… Hopeful MdB will review
UTC0013 - https://github.com/ArduPilot/ardupilot/pull/14984
- Important safety fixes
- Enthusiastic partner willing to test stuff
- Randy will look at
UTC0016 - https://github.com/ArduPilot/ardupilot/pull/14956
- Fixed loiter-to-alt with terrain target
- Peter will look at it and merge it if he doesn’t spot anything wrong
- Use same altitude for condition
- Terrain is tricky
- On each loop you have to track to go over a mountain
UTC0020 - https://github.com/ArduPilot/ardupilot/pull/14554
- Disable commands for unimplemented functions
- Apm_config.h going away?
- Make it easy for users to disable?
- -Wundef really ought to work for us - why is it not working?
- Make one build with -Werror
- Probably won’t pass when rebase
- Peter will rebase it and see what happens in CI
UTC0029 - https://github.com/ArduPilot/ardupilot/pull/14452
- Is this going to break Solo?
- Is there anything out there looking the command-ack?
- If nobody uses the message then nobody sees the ack
- Does this improve life for any user?
- MissionPlanner needs to change to using the mavlink command
- This won’t get merged. It should be removed when we stop handling set_mode
- QGC also uses SET_MODE
- The ack makes it into the tlog which makes it rather useful
UTC0042 - redux on the adsb avoidance code
- Sam and Tom will take this and run with it
UTC0051 - Plane update
More compass issues, confirmed by Sid
- Compass ordering used wrong variable
- Reordering on boot wasn’t working
- Variable wasn’t initialised
- Reboot is currently required to change ordering and stop using a compass as primary
- This was a fairly fundamental rewrite of the compass ordering
- You have to make sure an autotest fails when the functionality is broken
- No autotests for the compass priority stuff
What’s the expectation with the reordering?
- Where is the behaviour declared? Need to document the device ids
- After you do the reboot after doing the reordering then the compass IDs should align with the compass priority IDs
- Graphing the three compass can be very confusing
- Graphing didn’t align with the compass dev ids
Second mag popped up
- If primary compass dies
- The EKF does not switch to a backup compass
- Huge shock to both tridge and Randy and Peter
- Test for switching compass is around the test it uses to switch
- Never runs test if compass is unhealthy
- Really, really bad for Copters
- GSF may save you on master
- Will still switch based on bad innovations
- Compass_use to zero didn’t force the thing to change
- EKF just stopped fusing compasses entirely, probably wrong
PR options for killing compasses….
All a bit sad at the moment
Tridge has been very tempted to remove the compass changes from the stable releases
- We don’t have the ability to test the code properly
- Randy thinks it might be too late to go back….
- Need a test plan
- What are we going to test, what’s the expected behaviour?
- The people doing the previous testing might not have understood the intended behaviour
- Need to make sure the offsets and diagonals shift
- Save before reordering, look at param diff afterwards
Autotest would be good…
Probably another beta for Plane once this gets sorted
UTC0059 - Copter update
- Leaning on the Plane changes on compass stuff
- Some sort of altitude issue with RTL?
UTC0118 - GSoC
- Heaps of good stuff on object avoidance and walking robots
- PH is working on documentation for the new stuff
- Matlab serial connection….
- Test new driver to get matlab to do pretend sensor
- Thien’s 435i camera has gone well
- Documentation coming!
- A partner has confirmed that a 435i has worked for them for BendyRuler avoidance
- EKF stuff isn’t mergeable yet
UTC0121 - close