Dev Call May 4, 2020

Issues & Pull Requests





1 Like

Attendee count (max): 28

UTC 1100 -

  • Draft PR for OSD support for setting parameters
  • Video!
  • Looking for feedback!
  • We have multiple different protocols for carrying this sort of thing
  • Param set via transmitter is a thing
    • Alex’s methods
    • Mavlite
  • This is stick-inputs OSD display stuff
  • There’s a third one which is Graupner
    • Arbitrary text on a few line display
    • Maybe also srxl
      • 4 lines of 13 characters, one at a time
        • Also use these for showing flightmode and whatnot rather than just statustext
  • How does this work?
    • Same way that the read-only PR works
    • Two new screens
      • Set of 8 OSD param settings which set where it is on the screen and which ID
        • The IDs are not persistent
      • Can only do 8
  • Would like to be able to do entire parameter tree
  • Users could set parameters to use using the GCS
    • So they have a set to modify out at the field
  • [9:07 AM] (Channel) PH: i guess you could have a screen of pre-sets and then the search tree
  • Store token numbers which are persistent?
    • 32-bit number
      • Only useful if you’re using FTP to transfer your parameters
    • Could store as two parameters
      • key/index
  • [9:08 AM] (Channel) PH: can you have the param to change the params on the osd on the osd?
  • Can’t really use the index id as when firmware is updated the OSD parameter things will break
  • A new storage area for OSD display data?
    • Lack of metadata around ranges is still an issue
    • Don’t have metadata like ranges available
    • Ranges on our floats are very, very large
      • Some count to hundreds, some are 0.01 increments
      • Change things to be a percentage?
        • Moving from zero would be a problem
  • Bitmasks?!
  • Enumerated types
  • GCS has the metadata…
    • It could provide the metadata
    • Alex stores parameter, min/max, increment and description
    • MissionPlanner and Alex’s GUI handle all of this nicely
    • Lots of parameters?
      • Descriptions are still a problem
  • Will come back to this one

UTC1118 -

  • Stack size seems good
    • Param-ftp-sys stuff all merged
    • Stack checking
      • Disarmed is a panic
      • armed will try to keep flying with the memory corruption
        • Internal error in this case
      • First 4 characters of name of thread provided
  • Srxl is 200 bytes of max-stack
  • 296 left
  • Is there some way we could cross codepaths that have big buffer sizes?
    • Send text, for example
      • It happens to be protected
  • Merged!

UTC1123 -

  • FFT enhancements
    • Definitely not ready
  • Already discussed pre-call

UTC1124 -

  • Add support for custom compass rotation
  • Requested changes have been made
    • Name-change and dynamic allocation
  • Merged!
  • [9:26 AM] (Channel) TomPittenger: why do we exclude periph?
  • [9:27 AM] (Channel) andypiper: @tom because the euler claculation drags in something that blows up the flash size

UTC1125 -

  • Global check if @Values is increasing
  • People were raising PRs to keep things in order
  • Tridge doesn’t like the new ordering on many of these
    • [9:27 AM] (Channel) tridge: // @Values: -256:External only (0xFF00),-1:All (0xFFFF),0:None (0x0000)
  • Tom: Most of these are improvements
    • The negative ones are counterproductive
      • Negative because of historical problems with type widths / conversion to floats
  • [9:28 AM] (Channel) tridge: -6146:NearlyAll-AC315
  • Default or zero would be nice as the first one
  • Can now properly transfer int32 values using ftp
  • [9:30 AM] (Channel) TP: sounds like we’re wanting to reject this PR. That woudl be a bad idea. Lets take in the good ones, leave out the “bad” ones and move on
  • [9:30 AM] (Channel) TP: can we figure out the “known good” ones that we know we’ll accept?
  • [9:31 AM] To Weekly devcall: @Tom: the point of this PR from my perspective was that things would get enforced somehow. So we don’t do this call again in a year :slight_smile:
  • [9:32 AM] (Channel) TP: @peter we have lots of those discussions and nothing happens because of a stupid corner case. progress is good
  • Special-cases?
  • Attitude control input time constant reverses order so very-crisp is the top one
  • Cherry-pick out the good ones

UTC1137 -

  • Battery voltage
  • Slewrate works fine
    • Why?
    • Applied after this stuff
  • Shouldn’t touch manual throttles
  • [9:38 AM] (Channel) MdB: auto only I think…
  • [9:38 AM] (Channel) MdB: don’t mess with manual being a passthrough personally :slight_smile:
  • Watt limits?
    • This is a tuning thing
    • Not directly comparable
  • Exempt which modes?
    • Just manual?
    • Fbwa?
    • Huge range in throttle position charged vs discharged on 18650-style cells?
    • This can only range throttle so stopping shouldn’t be a problem
  • Reversed throttles?
    • Still works
  • Failed voltage sensor?
    • Any limits?
    • Does nothing if resting estimate voltage is <25% of minimum
  • This can push up your throttle on landing
  • High-voltage on battery pack?
    • Constrained away
  • merged!

UTC1139 -

  • AP_Scripting add support for dataflash logging
  • Ready for a full review
  • Any valgrind test?

UTC1147 -

  • Translation data?
  • Moves first waypoint with coordinates to point where you switch to auto mode
  • Orientation comes from home point to auto mode change point
    • Probably not the right way to do it
  • This is calling out for a script
    • Problem is the intended board doesn’t have scripting
    • 1MB board
  • No GCS available
  • Using for soaring
  • 9:56 AM] (Channel) RM: Peter Barker’s suggestion is we set the frame, on the MISSION_ITEM to MAV_FRAME_LOCAL_NED
  • [9:57 AM] (Channel) RM:
  • [9:57 AM] To Weekly devcall: Thanks Randy.
  • Problem using frame?
    • Relative to current position
    • Relative to where you entered auto
    • There’s BODY_NED
      • Not relative to current
    • 20 waypoints?
  • Too much maintenance?
  • Part of AP_Soaring?
    • Too much maths in common functions?
    • Advance-current-nav command for example
  • Other operators want things relative to home location, not to where you entered auto
  • [10:00 AM] (Channel) MdB: I’ve heard the desire to rotate but how people want to define where that comes from is hard, hence my preference for letting scripts do it…
  • Fewer and fewer boards over next few years that can’t do scripting
  • Maintenance cost on this is too high
    • Specific use case
    • 2kB of flash and lots of code
  • Lots of capable chips coming out
  • F7 is where things should be
  • Conditional compilation?
    • If it was nicely separated
  • [10:06 AM] (Channel) PH: is there any hope of getting scriptting when we drop the EKF?
    • Can we fit it now we don’t have EKF2 on them?
  • [10:07 AM] (Channel) RM: Willy, thanks very much for the effort on this PR…
  • [10:08 AM] (Channel) MdB: lua ate a fair amount…
  • [10:08 AM] (Channel) MdB: and then lua is probably gonna be held up on 1MB boards quickly…
  • Tridge will add something to the PR
  • [10:13 AM] (Channel) PH: its totaly worth the upgrade of flight conroller to get scripting and lots of other stuff BTW

UTC0015 -

  • Style guide
  • Constants aren’t really what matters
  • Merged!

UTC0019 -

  • Merged
  • Old outdated commented out message definitions

UTC0019 -

  • Has-destination and is-location stuff
  • Some units stuff
  • Merged

UTC0022 -

  • Should try a smaller SD card on exfat
  • Asked the author to tell tridge what compiler he’s using

UTC0025 -

  • Merged

UTC0029 -

  • Shut down motors when parachute released
  • Disarm by default
    • But should be able to rearm
  • Disable disarm checks if you were flying when parachute popped

UTC0031 -

  • Redo safety switch stuff
  • Behaviour switchable using parameters?
    • Hard to get into iomcu
  • [10:34 AM] (Channel) MdB: We worry about integrators winding up on plane I think
    • We reset integrators when safety switch is enabled
  • Not many pins on the F103 available
  • Either done as a script
    • Force safety state
    • AP_Button use pins off the FMU rather than IOMCU
  • Should make sure throttle isn’t wound up when estop is enabled on Rover
  • [10:38 AM] (Channel) NN: perhaps a digital signal out on one pin, through a switch then into another I/O sense pin. On disconnect, we switch to user defined state. (hold etc)
  • [10:39 AM] (Channel) PH: I’m fairly sure the RC option E-stop on rover doesn’t zero integrators
  • [10:41 AM] To Weekly devcall: @Peter_Hall could be fun to see what happens in copter in Loiter mode with full throttle and the RC channel option asserted to disable motors…
  • Use a button and scripting?
  • Does this need to be on IOMCU?
  • Boards with no IOMCU would seem to make sense
  • Two auxillary ports, one talking pwm to another
  • External safety switches are supported
    • So API is in place for AP_Button to manipulate safety switch state
  • mRo CAN node with safety button on it?
  • Will be discussed more on partner’s call tomorrow when Nick has sound working
  • [10:45 AM] (Channel) NN: I think the end action should be user param. disarm/hold/pause etc

UTC0048 -

  • Could make this come from the option bits
  • Set attitude target / set position target
  • Don’t honour these under avoid-adsb
  • merged!

UTC0051 -

  • Refactor
  • What’s the definition of “guided”?
    • Uses the external guided commands?
    • Able to accept position targets from external systems
  • In_vtol_mode
    • Lots of logic
    • Vtol loiter in ADSB?
    • [10:54 AM] (Channel) MdB: i dont know if that even works now honestly :smiley:
    • [10:55 AM] (Channel) MdB: I had that thought while reviewing :smiley:
  • Needs to be reworked for previous change (avoidadsb doesn’t do external commands any more)
  • Should probably all be changed to just be mode-guided
  • External override stuff seems to have a bug in it
  • Attitude overrides in ADSB?
    • Shouldn’t be the case
  • Most things should just be MODE_GUIDED
  • This PR will probably just move to checking against &mode_guided
  • [11:00 AM] (Channel) Michael_duBreuil: Despite the outcome I think this flagged real bugs so thanks!

UTC0101 -

  • Avoid extra work
  • merged!

UTC0104 -

  • Use check-failed-for-arming-check
  • Dead-man’s-disarm-switch
  • Merged!

UTC0108 -

  • Change autotest output format
  • Merged

UTC0110 -

  • Stop returning unsupported for a command we do support
  • Remove comment and can then be merged
  • Should be using temporarily rejected

UTC0115 -

  • One disk block could map to two locations
  • Changes the assignment of lat/lon
  • Tridge has script to pregenerate for region and upload
    • In AP_Terrain/tools
      • Two days to write it….
  • May need to download data
  • Someone is generating things for the entire world
    • 100GB or more?
    • Download would be ~13GB
      • Highly compressible data
    • Just Australia would be quite achievable, for example

UTC0020 -

  • Just make it emergency yaw reset, don’t include mag data information
    • Can be merged after that
  • Long strings are really bad on MissionPlanner?

UTC0024 -

UTC0037 -

  • No interest in having this in master
  • Closed

UTC0041 -

  • Needs to just be based off --debug
  • Performance problems? Don’t run --debug then!

UTC0042 -

  • Make landing detector more forgiving
  • Small accelerations / landing
  • 3D filter for a one-degree Z
    • Consistent with Copter

UTC0045 -

  • Allow scripting to set mission item stuff
  • Tridge and MdB looked at this
  • Points addressed
  • Ready for merge?
  • Commented out stuff in bindings?
  • One big commit?
    • Two commits, one for auto-generation
      • Want to not pre-generate
  • [11:49 AM] (Channel) PH: can we have a exmaple too if you have one
  • A whole bunch of comments from MdB
    • Michael needs to sign off on this
    • Tridge is happy enough with this

UTC0050 - GSoC update

  • Students have been announced!
  • We have 5 students
  • 2 have already been involved for a while
  • OA
  • Walking robots
  • T265
  • matlab/simulink

UTC0054 - Copter

  • 4.0.4 beta testing to start soon

UTC0055 - Partner’s call tomorrow

UTC0056 - Close

1 Like