With the invaluable cooperation of @peterbarker for the call notes
ArduPilot Dev Call 2018-05-01
Agenda: Dev Call Apr 30, 2018 2300 UTC
Attendee count (max): 16
UTC2300 - ESC telemetry
- Shape of mavlink telemetry packets is under question
- Debating whether we have one message covering 12 ESCs or one message per ESC
- Tridge went the middle ground - three messages covering four each
- Do we do lumps of four like this?
- Someone has a 16-motor vehicle?
- Hoping for MdB’s feedback on this (and there’s some on the PR)
- Temperature ranges are problematic
- ESC temps you only real care about overheating, so unsigned seems reasonable
- HW usually has a valid temperature range, which means signed might be good
- 127 maximum is too low
- More resolution on current seems like a good idea
- 650 amps per ESC is the current limit
- [9:08 AM] (Channel) RM: tesla super charger provides 340amps…
- NathanEick: I’ve hear of regenerative breaking – do we allow “negative amps”
- One message per ESC - overhead too large?
- Instance-field requires lots of GCS changes
- [9:11 AM] To Weekly devcall: @tridge what happened to the concept of a “count” field and abusing mavlink2’s zero-trimming?
- API for sending message gets very ugly
- 9:12 AM] (Channel) buzz_phone: id like to see milliamps, if possible, as thats how everyone reads the capacity of their batteries. ie 2000mAh etc
- [9:13 AM] (Channel) JW: people usually do not specify the instantaneous current draw of their vehicle in milliamps though
- [9:13 AM] (Channel) buzz_phone: …depends if you are using a glider or not…
- [9:13 AM] (Channel) NE: I respectfully disagree with miliamps because it’s a ton of extra zeros that I think are useless. Batteries are moving more toward Ah IMO. New batts are 2.0 Ah.
- [9:14 AM] To Weekly devcall: buzz: tat would make it easier for people working at the mavlink level - but we should be improving things at the presentation layer…
- [9:14 AM] (Channel) NE: I personally like native units for easy math, but that’s me. haha
- UTC2314 - no-fly-zones
- Very new issue
- Reuse geofence code for no-fly-zone?
- “Stay out” zone
- Would mean choosing one or the other as it currently stands
UTC2317 - https://github.com/ArduPilot/ardupilot/pull/8264
- fencing prearm
- Randy will look at that
UTC2319 - https://github.com/ArduPilot/ardupilot/pull/8256
- Fencing prearm
- Will we get use out of them?
- Jacob will get utility out of them
- Tridge doesn’t like the burden it puts on developers for limited gain for few people
- Used to run these on autotest
- If we had an enthusiastic developer who wanted to go through everything and mark it up then we might auto-generate this stuff on autotest etc
- But this is an ongoing thing
UTC2324 - NuttX and absent-FD
- Only way under PX4 HAL to get a NuttX shell
- ChibiOS always boots
- Tridge is leaning towards having NuttX always boot
- [9:25 AM] To Weekly devcall: @tridge if we care we could have a flag-file on the SD card!
- [9:25 AM] To Weekly devcall: touch /media/pbarker/SDCARD/give-me-nuttx
- Always open log files on boot?
- Jacob will progress this
UTC2330 - batch-sampling at sensor-rate logging
- Ffts at much higher frequencies
UTC2336 - send-parameter-value-all PR
UTC2339 - analogue pin logging and mavlink transmission
- Tridge has code!
- Tridge is concerned about how many mavlink packets we’re adding
- Minimum 1Hz rate
- A parameter with a number of bits indicating whether to stream a message
- Weekly devcall: SR0_MSG_MASK
- [9:46 AM] (Channel) NE: Those are super unclear btw
- [9:46 AM] (Channel) NE: SR0, SR1, SR2 documentation is VERY lacking
- [9:46 AM] To Weekly devcall: streams need to die
- [9:48 AM] (Channel) NE: Low-latency AHRS telemetry would be GREAT.
- [9:48 AM] Unmuted.
- [9:48 AM] To Weekly devcall: @Nathan yep
- [9:48 AM] To Weekly devcall: millisecond resolution
- Support for built-in OSDs is coming
- Default streamrates have to take into account write-only devices like OSDs
UTC2351 - set-time PR
System time - not ready to merge
Time stuff is hard
Patch may be seeing scope creep
- Simple patch - don’t account for crystal being off
- First time source wins
- This is what original patch did
Now we are slewing time on autopilot to match gcs time coming in
- This is significant, one second in 10000
- Necessary for ros non-gps positioning
We are tiering time sources coming in
Gps beats rtc beats gcs, this is not sufficient
We need master clock
Multi-gps situation is covered
Are we coordinating with mavros maintainers?
- One has commented on pr so they are aware
Similar timesync work going in px4 right now intended to go into mavros. Coordinate?
This patch is not mavros specific, it just allows synchronizing to an external time source
We may need to support a different message or something to support whatever api they come up with
No problem to just feed that in
Randy: this part needs to go in it’s ardupilot work and we need it
UTC 0004 - https://github.com/ArduPilot/mavlink/pull/55
- 16 seems a little overkill
- Wheel distance is a strange name
- Randy will look at it
UTC0007 - avoidance message and mavlink
- 220 bytes…
- Why use the same message for differently-shaped data?
- We have lots of IDs available
- PP: these different things are getting confusing!
- We did have co-operation
- It didn’t work out well in the long run
- We need basic time sync
UTC0020 - AUVSI update?
- OB will be there tomorrow or the day after
- Nobody on call to give us an update
UTC0021 - GSoC announcements
- Good engagement from several students!
- A few students do need to step forward and engage
- Some students were on call, now they have left
- [10:23 AM] (Channel) pp: Congratulations, GSoC 2018 Ardupilot Students!
- Some requests for hardware are coming in
- Funding committee wants to see proposals! Now!
- ~$800 - includes a TX2
- [10:25 AM] (Channel) : does he need a tx2??
- Is it worth it?
- Everybody uses TX1/TX2 in the video world
- [10:29 AM] (Channel): unless he is doing some computer vision work or crazy number of cameras I don’t think he needs it. What he does on a rpi should apply to tx2 others have the hardware to verify. v4l2 and gstreamer do not care
- Point of contention on whether tx2 is necessary
- Equal to all?
- Pool of hardware?
- Get hardware back at end?
- Funding committee will look at this
- Randy will get him the hardware and then fight with funding committee
UTC0034 - motto announcement
- Versatile, Trusted, Open
- Good thing from marketing committee!
- Elections coming for revitalised marketing committee
UTC0035 - F4Light
- Do we CI it?
- Do we autotest it?
- Build a tag?
- Tag would have to be in the repository
- And the relevant commit as a branch
- Night-ghost works outside master
- Would be nice to get F4Light working with waf!
- Tridge wants a warning-level thing in CI rather than simple errors
- Resolution: leave things as they are
UTC0042 - companion
- New simple companion/APSync release soon
- Wifi client support can connect to wifi network - only real new feature
- Tested on raspberry pi
- Cross platform support is problematic tx2 has wierd funk
- Will have tx2 and tx1 image
- Will add support for pi 3B+
- Workaround to upgrade existing image
- Possibly start to support banana pi - reasonably big community
UTC0049 - reference build for Plane
- Nobody knows anything about this on the call
UTC0049 - ChibiOS update
- Thanks to Randy for putting pages up!
- USB IDs issue
- 3DR PixHawk ID wasn’t great
- Windows7/Windows8 require special drivers to change
- Bootloader stays the same ATM
- ST-micro’s vendor ID
- String IDs have serial in them
- And the serial number for the device
- Different COM port for each device you plug in
- COM port 35, 36
- Hex have their own vendor ID
- Do we present a different vendor ID based on the board you’re running on?
- Base it on a vendor ID in the bootloader?
- Use apjtool to set the vendor and product ID
- Windows 10 is good with cdcacm devices
- 7 and 8 not-so-much with separate driver requirements
- Unique IDs per board
- Tridge likes it!
- Some older programs might crash
- TODO item is to set IDs in strings from apjtool
- Pre-windows-10 users
- Will need st-com-port-driver
- MP should install this for Windows 7/Windows 8
- Board ID in manifest.json?
- String board ID instead of a board number
UTC0107 - px4v2 overflowing again
- Or it was yesterday…
- Rerunning things makes things work…
- [11:07 AM] (Channel) JW: that doesn’t sound good
- [11:07 AM] (Channel) JW: about the ci randomly failing
- [11:08 AM] To Weekly devcall: Might be that “multibuild” thing that’s going on
UTC0109 - AUVSI!
- Michael, Tom, Jaime and Jeff called in
- Battery failsafe stuff!
- Need to ping GCS maintainers to get support in!
- Randy will work with Michael on it
- Battery parameter pages are broken
UTC0110 - Copter and Rover update
- 3.6rc1 and 3.3rc1 are out
- Plenty of issues
- No crash-dramatic issues
- Unverified list:
- [11:10 AM] (Channel) RM: - pixracer not working on ChibiOS builds? ChibiOS and Pixracer
- Pixhawk mini will be able to use d-shot?
- New Loiter on TradeHeli, requires proper setup attention - Issue fixed with proper parameters and setup
- omnibus f4 pro included in release? no yet but in master
- Several of those have already been tested and seem to be Working For Me
- We need a test plan
- A test matrix for users to follow
- Share testing load with community
- Randy will put one together
- Tridge might get inspired
- Testing of AP flight characteristics rather than hardware
- Unless we have new hardware
- Nate’s testing of the last release for Plane was great!
- Bunch of extra coordination to manage results of test plan
- Any volunteer for “testing coordinator” for Plane
UTC0121 - return control to user sooner on SmartRTL
- Very late return of control
- Reduce accuracy instead of aborting SmartRTL when out of control?
- Invalid mission problems
UTC0123 - v53l0x
- Tridge did initial driver
- Some issues?
- Tridge is happy for people to chase these issues
- Stupidly complicated interface to hardware
- And out-and-out errors in the sample driver
- Want PRs!
UTC0126 - omnibus in release?
- Cherry-pick-in the hwdef.dat
- No risk to anything else
- Assuming there’s no extra sensor drivers etc
UTC0127 - log files and dates ChibiOS
- Related to the RTC stuff Peter is looking at
- Tridge and Peter will look at it
UTC0128 - colours on ChibiOS
- Need to check the three pin definitions
- Mucked up early in the port process, but tridge thought he’d gotten this right
UTC0128 - position-hold for Rover coming soon
UTC0130 - Plane update
- Flew master on quadplane on Sunday
- Beta process will now start
UTC0131 - Sub Update
- Beta tagged today
- Current limiting
- Usability improvements
UTC0132 - tracker maintainer
UTC0133 - https://github.com/ArduPilot/ardupilot/pull/8228
UTC0135 - https://github.com/ArduPilot/ardupilot/pull/6797/files
- Tridge and Jacob will look at
UTC0138 - Philip and HW
- Cube Orange
- Details to be released later
- Cube Pink being sent to Luis
UTC0138 - end
A big thanks to all that attended the call. Hope to see you all next week.