Dev Call July 23, 2018 2300 UTC

Development Team
1

**Issues & Pull Requests






Using MML for Tones

ArduPlane

  • 3.9.0 Update

Open Drone ID

ROS & ArduPilot

  • Update

SPI Liaison Vote

GSOC

Copter

  • Update

Rover

2

Attendee count (max): 24

Pre-agenda:

UTC2303 - tridge is on holiday

  • Picturesque photos to follow

UTC2303 - SPI liaison vote is open

UTC2303 - contribution of the month open ‘til end of call

UTC2305 - https://github.com/ArduPilot/ardupilot/pull/8982

  • RC channel trim
  • Tridge says we need a Plane 3.9
  • MP has been fixed
  • Upgrade experience will still be bad
  • Will MP fix bad trims?
    • Or just not make them worse
  • Using advanced parameter list is a fiddly way of fixing things
  • Tridge tried the average value if the value is 0
  • New patch only checks channels we are using
  • Loop over all channels and check for has-override instead in current patch
  • Way too much const-function
  • Patch that will be going in just skips checks on unused channels, taking into account overrides
  • Tridge wants this in quickly because it’s a bad upgrade path ATM

UTC2316 - CAN cleanup

  • https://github.com/ArduPilot/ardupilot/pull/8987
  • More CAN protocols can be added more easily
  • More Cleaning up
  • Still needs some testing
  • Sid split up sensor code into sensor backends
    • Increases size considerably
      • 57kB
      • Can not fit on px4-v2
      • Libuavcan size is a problem in lots of places
        • Pavel has seen the same thing
  • https://github.com/ArduPilot/ardupilot/pull/8972
  • Lots of boards with 1M out there
    • 60k is a lot
      • A lot of our new boards
      • 9 or 10 months of development of AP
      • JC: Can we use LTO?
        • Sid has tried but failed
        • Tridge has got it working for ChibiOS previously
        • Jon has had luck doing it with OpenMotorDrive
        • When using ar to create a library you need to add a plugin to AR
        • Maybe just do it with uavcan internally?
        • PB: would only need to do this for v2?
      • Is Pavel aware of the problem with templating in uavcan?
        • He is
        • Header-only libraries are bad news
          • And slow to compile
      • Doesn’t seem to increase as it is used more, which is odd
        • Adding baro drivers didn’t increase size
      • Increases compilation time enormously
  • Tridge says we need to fix this problem before merge
    • Hasn’t reviewed the code for other things
  • Most of our code is -Os for space optimisation
    • Some is -O3 for speed optimisation
  • FF doesn’t have time to chase ATM
  • Sid might be able to chase this
    • Forward-declaration seems to not cause the size increase
      • Even when doing subscriptions
    • Same symbol different sizes in different object sizes can be a problem
  • Francisco’s change doesn’t increase code size
  • Sid’s does
  • [9:33 AM] (Channel) LV: All this issues with optimising UavCAN and making it fit within 1MB isn’t this us trying to solve a problem that does not exist ?? Short of very few users that have UavCan devices, I guess whoever decides to use uavCan can easily use a 2M board !!!
  • [9:34 AM] (Channel) LV: and even more when we DO NOT control uavCan
  • Tom thinks “it’s too big” isn’t a good reason
    • Deprecate older features
    • Tridge thinks 60kB out of 2MB is too much
      • Thinks the pressure to get rid of the problem of size here should be relieved now, not after merge
    • ChibiOS build frees up 80kB
      • Using up 60 of 80 seems like too much
    • 50kB of drivers will probably come soon after
      • Tridge: Our typical drivers are 1kB - so are there 50 drivers coming?!
    • Tridge: If after 2 or 3 weeks effort we can’t reduce the size then we could put this in
      • #include of cpp files would work, for example
        • Unusual and ugly but better than what we have now
      • Giving up too early - need to try a bit harder
      • Concerns on scaling
      • Why 60kB now and not 120kB next month?
        • We don’t fundamentally understand why adding it to each driver doesn’t increase the size
  • FF, Jon, tridge should all brainstorm on this
  • Tridge would like uavcan to be smaller rather than larger
  • Maybe move to OMD?
    • Uses libcanard
      • For receive
      • Not for xmit
      • Doesn’t support redundant CAN interfaces
    • Some limitations on the way it defines messages
      • Size of structure on stack is always max
      • Uavcan doesn’t scale well with large messages
      • Uavcan messages are typically smallish
        • Hundreds of bytes
      • Would eliminate pool allocation by creating message on stack
  • TP: … we’re wasting effort like we did back in the APM -> STM transition days…
  • JH: i am looking to bring 10-15 new CAN devices in few months
    • Fuel flow sensor
  • FF has some efficiency improvements unrelated to these that should be brought in
  • Need to watch our bandwidth usage on CAN!
    • Particularly octoquad CAN ESCs will completely fill a bus, so any other traffic is unwelcome
      • But not allowing announcements removes one of the big advantages
      • May affect vehicle stability
    • Moving to 8Mbit (CANFD) will save bandwidth
    • 150us/message at the moment
    • Would drop to 40 or 50us
    • Peripherals would need to support CANFD
    • Some Cubes have three buses

UTC2347 - mavlink-over-CAN virtual serial port

  • Hasn’t been touched since PR went in
  • Packets are being lost
    • Tom doesn’t know why
  • Olly duplicated the work and could have not had to duplicate it if this was merged
  • Should have oodles have bandwidth
  • FF’s fix might fix the problem in this PR
  • Felt like sync loss
  • Need a CAN sniffer on this
  • We have more uarts now so this will need a rebase
  • Tridge and Tom will work on this next week

UTC0001 - MML for tones

  • We have rttl (Nokia ring-tone)
    • Used for Linux and ChibiOS
  • MML used on HAL-PX4
  • Jon wants to use MML on all boards as we have a richer set of tones
  • No beeps when calibrating compass on ChibiOS ATM
  • Tridge would be happy to switch to MML so long as it is constant across the board
    • One definition of our tones rather than two
  • Make the HAL simpler
    • Frequency of buzzer
    • Move driver logic into AP_Notify/ToneAlarm
    • Unify tones
    • Same on all the boards
  • Small change went in to tones
    • Play tones via mavlink
      • Was limited to 30 character string
      • Mavlink2 extension makes it 230-length-strings
      • Luis is trying to get new tone-sets together
      • Needs GCS support

UTC0005 - https://github.com/ArduPilot/ardupilot/pull/7970

  • Needs author on call to discuss

UTC0007 - https://github.com/ArduPilot/ardupilot/pull/8814

  • Can remove devcall from this one

UTC0008 - Plane 3.9 with tridge

  • Needs to be tested in SITL
  • Which tridge will do today
    • And then push in
  • Considering changing default of auto-change compass orientation in 3.9 to enable
    • Tridge is very confident in the code
    • And Plane will cope
      • MdB: kind of
        • Can take time to reconverge
    • Build paths where people walk
    • People have assumed that the orientation is magically determined already
      • This does that
  • Currently 3.9 will just fail the calibration
    • And not inform the user very well
  • GCS could help out a lot here
  • Randy thinks orientation isn’t the big issue
    • He thinks the internal compasses on the flight controllers are garbage and need to be turned off
    • Should we change to disable internal compasses automatically?
    • Use AP_Declination and yaw to eliminate compasses
      • Ala SkyViper
  • Maybe 3.9.1 will be auto-fix
  • Maybe do it in hwdef.dat?
    • Already do this for other places like compass
    • MdB bad from support perspective
    • More DIY-ish people
    • So tridge will enable it on some boards but not others

UTC0020 - Rover

  • 3.4rc1 is out for beta testing
  • Thanks to FF for pushing the buttons
  • Pivot-turn fix
    • Would pivot when it didn’t need to

UTC0020 - Copter

  • Relays fixed in last week
  • Rc7 will be out later this week
  • Compass issue on PixRacer fixes
  • Dshot motors starting/stopping when vehicle disarmed
  • Loading firmware issues
  • Getting back to NuttX-based is problematic
  • Vl53l0x lidar
    • Weird error message
    • “Not owner of 2909” error message
  • Removing Make?
    • People are using bad instructions

UTC0029 - ROS

UTC0030 - balancebots

  • Can drive in auto in SITL
  • Not tested outside yet due to flooding
  • Need reference frame documentation
    • Randy will look at

UTC0032 - Arnav

  • Great progress with APWeb interface stuff
  • Neds to document and PR

UTC0033 - opendroneid with Tom

  • Intel is moving forward with a demo for it
  • Mavlink support
  • Intel in working group with the FAA
  • Transponder on every drone on the planet
  • Over bluetooth
  • Semi-short-range
  • How does it connect to flight controller?
    • Uart
  • Mavesp8266 firmware that does a broadcast frame?
    • No additional device required
    • No uart required
    • Not bluetooth, of course
    • Wg looked at doing the wifi thing
      • Bluetooth was better for cost/size apparently
      • Bluetooth doesn’t pair
      • 29-byte-packet once/second
  • New rules in Europe
    • Will go with the worldwide recommendation
  • Encode information in SSID announcement packets on WiFi
    • This was used for indoor-positioning using esp8266 dongles
    • Everyone knows how to receive SSID announcements
  • Regulations seemed to say things had to be immutable last time this came up
    • Hopefully they instead say it can’t be modified without losing certification
  • This might be a good time to push out some sort of open solution
  • There were some very evil/invasive/expensive/space-hungry etc
  • Intel’s proposal is one of the least-bad ones that’s come out of hte FAA’s group
    • Easy from hardware POV
    • $2-$3 in bulk
  • Even something like SkyRocket’s drones would be covered?
  • Bluetooth is puzzling
    • Drones already have WiFi on-board
    • The two are roughly equivalent
    • WiFi consumes a 20MHz channel
    • Bluetooth is 1 or 2MHz
  • Portuguese regulator is very keen on implementing whatever comes out
  • Intnl solution package
  • Us solution package
  • Convergence way down the road
  • https://github.com/markszabo/FakeBeaconESP8266
    • Shows it’s pretty easy to do
    • People on committees don’t understand how WiFi works
      • Think you have to drop WiFi
  • Spamming the SSID space
    • Add filter characters?
  • Production drones is the focus
    • DJI-style
    • Forward-fit only
  • LV: would have to register your drone
    • Put sticker on the drone which has your ID
    • Closed-unit-solution
  • Above 250g
  • Below 250g not required
  • We should push the “use WiFi” solution
  • SSID beacon announcements might be able to encode the data without creating an SSID
  • Jeff - ship has sailed
  • https://mrncciew.com/2014/10/08/802-11-mgmt-beacon-frame/
  • Maybe a wifi-connected bluetooth transceiver the drone talks to?
  • French company is already demonstrating in Portugal
  • EASA solution
  • 200+ companies which might not be bound my EASA
  • But EASA means most Europe might all be stuck with what they’ve got
  • Sid: Modifications to AP to support regulations
    • Request-for-logs which the drone has to return

UTC0032 - UAVCAN redux

  • Sid thinks he has a fix
  • Don’t include stuff you don’t need
  • Forward declarations may ease this
3

you seem to speculate a lot here, so let me please clarify:
I made good use of magicrub’s ringbuffer driver (and widely acknowledged this everywhere) but otheriwse did not duplicate the work. Please note:

  • it is stated that the PR is not fully working
  • it only offers one UART tunnel, and not several (and it’s unlikely that the losses get better with more tunnels)
  • it can’t handle different baudrates as it is needed for e.g. GPS
  • I find it logically flawed in structure, it should behave like a serial and be usable like a serial
  • waiting for somethig to happen or to be merged has not been a productive approach at all in the past

Because of these limitations, I would have done my stuff even if the PR would had been merged. My time was not wasted here, and I’m happy where I am with this. :slight_smile:

All the best