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
- https://github.com/ArduPilot/ardupilot/issues/8255
- 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
- Merged!
UTC2336 - send-parameter-value-all PR
UTC2339 - analogue pin logging and mavlink transmission
- AP_ADC
- Tridge has code!
- https://github.com/SkyRocketToys/ardupilot/blob/skyviper2018/libraries/AP_HAL_ChibiOS/AnalogIn.cpp#L288
- 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
-
https://github.com/ArduPilot/ardupilot/pull/8121
-
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
- https://github.com/mavlink/mavlink/pull/856
- 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??
- RPi?
- 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
- Maverick
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.