Attendee count (max): 23
Speak now or report a bug later!
Interesting to see how Rover is calling lots of stuff on the flightmode class; do like we do in Copter?
UTC2308 - new HAL CPU class
Some of this has been merged
F7s have twice the dmips (performance)
Adding fourth compasses / IMUs etc etc sounds like a good idea!
How do we identify CPUs that can do that?
We’re doing opt-in for features
HAL_CPU_CLASS is probably dead after the already-merged stuff, unless we add a new CPU class
Statustexts pending is large on a cpu class
Make this larger on all boards?
Lots of memory ATM
Memory layout on H7 is working
[10:13 AM] (Channel) MdB: so more status texts everywhere is better
[10:13 AM] To Weekly devcall: I’m quoting you on that @MdB
[10:13 AM] To Weekly devcall: Out of context.
[10:13 AM] (Channel) MdB: CONTEXT PETER!
[10:13 AM] (Channel) MdB: CONTEXT REQUIRED!
[10:13 AM] To Weekly devcall:
[10:14 AM] (Channel) MdB: _status_capacity should probably be scaled vs port baud rate rather then fixed size as well… After a certain point super stale statustext is actually more damaging…
RPi tends to use up a lot of CPU on IO - e.g. SPI
H7 doesn’t use much at all due to use of interrupts
Io is very fast on stm32
Probably do faster loop rates on H7 vs Pi
Memory vs cpu limits
312K is smallest we support on an F7
Largest is 512k
#ifdef based on RAM size
[10:16 AM] (Channel) buzz_mobile: you know the raspi can be run in bare-metal mode yes? (no linux)
[10:16 AM] To Weekly devcall: @buzz someone ported ArduPilot directly to the hardware?!
[10:16 AM] (Channel) TP: perhaps one core is ArduPilot, rest of cores is Raspian
[10:16 AM] (Channel) TP: ?
[10:16 AM] (Channel) buzz_mobile: …no but I think u just volunteered…
[10:16 AM] (Channel) MdB: buzz: congrats!
[10:17 AM] (Channel) MdB: /me selectively read that as buzz volunteering
[10:17 AM] To Weekly devcall: /me is assuming that was Tom volunteering, since he has a scheme.
Tom is tempted to kill this new CPU class
Tridge points out that it gives you a central point to change stuff
You could use hwdef to do that
UTC2310 - set home changes
UTC2328 - rejecting set-params based on component id
Will this break GCSs attempting to send to stuff
Apparently people do use the camera component id
Randy: Our component id or broadcast should be the ones we accept
Mavlink spec seems to say you should
[10:30 AM] (Channel) Michael_duBreuil: I can actually tell you I send to camera per the spec…
Even if it hasn’t sent a heartbeat
Hard-coded component ID
Don’t want to inadvertently set parameters where
Make SYSID_ENFORCE a bitmask?
There are parameters on cameras
CAN stuff should be registered in routing
[10:29 AM] (Channel) edwin.hayes: The issue is that the things which talk on different cIDs tend to not also send heartbeats, which is required if you want the routing rules to behave as expected.
[10:30 AM] (Channel) MdB: that is a bold protocol assumption…
[10:30 AM] (Channel) MdB: I can actually tell you I send to camera per the spec…
[10:30 AM] (Channel) MdB: regardless of heartbeats…
[10:30 AM] (Channel) edwin.hayes: Correct; and we definitely do this.
[10:31 AM] (Channel) buzz_mobile: route or drop.
[10:31 AM] (Channel) TP: PWNd
[10:34 AM] (Channel) MdB: (I don’t do camera params so I’m fine)
[10:35 AM] (Channel) edwin.hayes: This issue also used to cause companion computer to reboot the flight controller, so it’s definitely an issue which needs to be addressed.
[10:35 AM] (Channel) edwin.hayes: Not parameter related, but same issue.
[10:36 AM] MarkW moved in from Ardupilot mumble by the server.
[10:36 AM] (Channel) MdB: some stuff like the reboot I’d maybe always force the ID to be correct
[10:37 AM] (Channel) MdB: I’d argue reboot/arm/disarm should always be forced to match
[10:37 AM] (Channel) edwin.hayes: Presumably other ‘DO’ commands would also be accepted without being the right device.
[10:37 AM] (Channel) buzz_mobile: it’s better to be more strict and give a decent warning message than to continue to be liberal without any user notification.
[10:38 AM] (Channel) edwin.hayes: Arming, disarming, etc.
[10:38 AM] (Channel) buzz_mobile: I think we should break that, sorry.
[10:38 AM] (Channel) Michael_duBreuil: ha no I can’t
[10:38 AM] (Channel) Michael_duBreuil: that has shipped units
[10:38 AM] (Channel) Michael_duBreuil: and I think I’m correct…
[10:39 AM] (Channel) Michael_duBreuil: we are a camera (sometimes)…
Have to preserve existing behaviour
Special cases for arm/disarm
G_Dt may not be calculated or used in the best way possible
When scheduling is off you can stuff up your integrators and D-terms
Missing loops would be bad in Plane ATM
[10:45 AM] (Channel) MdB: can’t some stuff (such as DCM) just call the scheduler directly rather then try and resolve G_Dt to be globally/best?
[10:42 AM] (Channel) MdB: plane primarily uses it for quadplane stuff… Consitency with copter seems valubale there though…
[10:42 AM] (Channel) buzz_mobile: it’s bringing the platforms closer together… maybe save fixing outliers for later.
[10:43 AM] (Channel) buzz_mobile: …or keep two timestamps.
[10:45 AM] (Channel) MdB: can’t some stuff (such as DCM) just call the scheduler directly rather then try and resolve G_Dt to be globaly/best?
[10:45 AM] (Channel) edwin.hayes: Wouldn’t a better solution be to just reject the integrator updates where the timestamp is too long for the assumption of constant [acceleration] across the sample period?
[10:45 AM] (Channel) MdB: we do do that edwin at some point
[10:45 AM] (Channel) MdB: At least on some of the controllers, maybe not all of them though
[10:46 AM] (Channel) edwin.hayes: Ok cool. Seems like a prudent thing to be doing.
[10:47 AM] (Channel) MdB: agreed
[10:47 AM] (Channel) RandyMackay: https://github.com/ArduPilot/ardupilot/commit/f06fdf330efaf8edb5c92374fd24cc328651e501
[10:47 AM] (Channel) MdB: Scheduler should maybe retain the smoothing internally for you, but yeah I support fetching
[10:47 AM] (Channel) MdB: https://github.com/ArduPilot/ardupilot/pull/7223/commits
Needs more investigation
We should probably reject a request to stream a mavlink2 message out a malink1
We will stop advertising mavlink1 links as mavlink2
Old SiK radios
Copter will have a behaviour change
Won’t set bit
Copter can do terrain following with either terrain OR rangefinder
Issue on Copter 3.6 with boards that don’t allow terrain without an SD card
Can go in in when it’s rebased!
Does it make things larger?
Can go in once it’s rebased
Are people generally happy with this?
[11:13 AM] (Channel) Michael_duBreuil: do we always have frsky/devo objects allocated?
[11:13 AM] (Channel) Michael_duBreuil: I’m thinking this says yes…
[11:13 AM] To Weekly devcall: @MdB vehicle configuration #defines ATM
[11:14 AM] Unmuted.
[11:14 AM] (Channel) Michael_duBreuil: aww the memory usage!
[11:14 AM] (Channel) Michael_duBreuil: ideally if init doesn’t find anything we delete the object…
[11:15 AM] (Channel) Michael_duBreuil: is this faster/is the compiler not essentially doing this?
[11:16 AM] (Channel) Michael_duBreuil: … need LTO… these should be the same with proper optimizer
Need to make sure _resend_uart handles signing and mavlink1 vs mavlink2
Pymavlink can force malvink1 or mavlink2
Combine with testing for signing
_resend_uart doesn’t fix the sequence number!
The 2D vs 3D thing should be reverted
[11:34 AM] To Weekly devcall: @MdB I got scope creeped on this one on a devcall, and look where that got me
[11:34 AM] (Channel) MdB: A great test case!
[11:34 AM] (Channel) MdB: For autotest!
[11:34 AM] (Channel) MdB: So totally worth it
Randy is planning on removing the fallback to DCM in Rover
Velocity estimate errors cause DCM to go insane
Copter can be flown on DCM
Testing DCM: Set an auto mission and set ekf-type-0 and see what happens
Maybe add an option bit to disable fallback to DCM?
Dcm-vs-ekf is one of the first tests tridge does when looking at a log
Closed this PR - add patches to Rover to fix things rather than hacking DCM
Tridge to look at
There is a behaviour change
Concern is lower-limit-start-ms being reset
Precision landing for quadplane
Autotests should be straight forward!
Real vehicle tests required
Moved to NeedsTesting
Universal emergency stop
Should_estop looks good
This looks good
Should look at the Copter duplicate-state problem once it has gone in
MdB to look at
Parachute / sink rate
This will apply to Copter as well
Needs some rework on commit comments
Parameters that aren’t used should be marked as unused
… but would be better to have them work on Copter!
Tridge has added comment to PR to help with git
UTC0106 - Copter and Randy
Copter can lean past angle max
Matek405 wing std or wing boards don’t boot
Notify 199 doesn’t boot
External compass causes failures
Three users have reported
Tridge has put board on desk in front of him to try to remind him
Zubax won’t initialise when using ChibiOS when using battery
3.6.6 Out with a bunch of fixes (see release notes)
No specific plans for 3.6.7 at this point for Copter
Required by upstream mavlink?
Tridge has wanted for a while
Needs to be tested under ArduPilot
Should generate exactly the same headers with and without this patch
[12:11 PM] (Channel) MdB: We don’t just recurse to accumulate includes? oO
Could remove include from ardupilot xml for adsb otherwise XML will be included twice
UTC014 - Randy and Rover
Rover 3.5 is out
Including BalanceBot in auto mode
An do object avoidance in ROS on master
Will drive around avoiding obstacles
Want to integrate it better to GCS
Help would be nice!
Hopefully an Antenna release in next little while
UTC0015 - Plane and tridge
No real news
Pending release but hasn’t gone out yet
UTC0016 - Randy and Funding Committee
Concern about partner renewals
Committee is getting back on top of the problem
Tridge is chasing SPI on getting payments out for contribution of the month etc