Dev Call July 13, 2020

Issues & Pull Requests




1 Like

Attendee count (max): 26

UTC1100 -

  • Initial implementation of msp protocol
  • Port from betaflight
  • Mspv1 and mspv2
  • Rangefinder and optical flow inav messages
    • Matek3901 combined sensor
  • DJI FPV goggles
  • Telem implementation that works from both a master and one-wire mode
  • Tested by a lot of people
    • DJI stuff in particular
  • Lots of parameters
    • Particularly for layout
    • Would be nice to integrate this with OSD somehow
      • Already have multiple backends
        • SPI and SITL
      • AP_OSD_MSP
      • Backend that pushed the data into a structure
        • x/y coordinates for each element
        • MSP code could live separately and access structure via singleton
        • Access elements for sending out protocol messages
        • Intermediate data structure in AP_OSD
        • There is a struct already which holds the MSP telemetry
        • Currently we have a printf function into the OSD backend
          • Instead we should make the backend function take a format
          • But some sort of other interface which provides a raw value
          • Would not work well for messages
            • But well for e.g. floating point numbers
          • Existing backends would only look at the formatted string
            • MSP backend would look at the floating point number
          • MSP OSD could push into existing structure?
            • Or could go the other way, too
        • Key change would be to change the API on AP_OSD_Backend to provide not just strings but token/value pairs
        • backend->write(x, y, false, “%3d%c”, (int)u_scale(TEMPERATURE, esc_temp), u_icon(TEMPERATURE));
        • Becomes
        • backend->write(x, y, false, OSD_TEMPERATURE, esc_temp, “%3d%c”, (int)u_scale(TEMPERATURE, esc_temp), u_icon(TEMPERATURE));
        • Or a second call:
        • backend->set_value(OSD_TEMPERATURE, esc_temp); with a matching backend->set_value_string(OSD_MSG, mymsg);
          • Scrolling would be messy
          • Might work for flightmode
        • Would we need a thread for msp in this case?
          • Potentially the MSP could run on the OSD thread
        • Could also look at having a register-token-at-position-with-format method
        • Alternatively:
          • backend->set_value(OSD_TEMPERATURE, x, y, esc_temp);
      • Using the same parameters would be great as MissionPlanner’s interface could be used for both
  • OSD via CAN?
    • Would need to include AP_OSD on all boards
      • Just exclude the SPI backends?
  • Composite values?
  • We should look at getting a set of goggles for Alex
  • Flow code needs looking through
    • Flow and quality, no gyro data
    • Use the timing-jitter-removal-code
      • receive_time_constraint_micros

UTC1100 -

  • Allow RC channel option be read by scripting
  • Get switch position rather than PWM
  • Also designates a switch for scripting
    • Directory in AP_Scripting for lua applets
      • E.g. smartaudio
        • Complete and seems to be working for power changes
        • Needs to know which channel is used for power changes
        • Multiple scripts with one script?
        • Parameters would be required to resolve this collision
          • Parameters are tricky…
          • Some method to associate parameters with a script
            • Associate an ID with a script
  • This PR does a static cast…
    • Should we just always static-cast things that are returned?
      • Could potentially shoot yourself in the foot…
      • Changing binding could lead to subtle bugs
      • Simple….
  • All generator edits will be reverted….

UTC1140 -

  • Simple fix on last week’s PR
  • Merged!
  • Trusting Andy on this one…

UTC1150 -

  • Nice cleanup
  • One small change from Randy to make then it can be merged

UTC1153 -

  • Chane between different sources based on a switch
  • GPS -> ExternalNav -> GPS
  • Randy flew underneath a metal roof, switch to external nav, then flew back out again and moved to GPS again
  • Two banks of sources
  • Proxy and posxy2
    • Switch allows you to move from one to the other
    • Only for EKF3 at this point
  • Randy would like more testers for this PR!
  • This already adds value
    • What more should we add to this before merge?
  • May help us move towards more EKF code cleanups
    • Particularly yaw handling
  • This is changing the defaults for some things?
    • Velocity-z now defaulting to baro?
      • Mistake
  • EKF magic values need to die
    • Use enum classes
  • How will this work with the affinity PR?
    • GPS affinity can still be happening
      • This is just use-gps-for-fusion
      • isfusionmodegps==3 now calls new class and asks for get-pos-source
  • Array of two AP_Int8 parameters rather than two separately-named
  • Resets are handled
    • E.g. T265 has own yaw source
    • Resets position and heading when switching
      • Controllers are aware of this and jump their targets
      • No twitches except for in altitude
        • We need to notify the z controllers
          • SCurves fix this!
  • Only tested in loiter for the time being
  • Bugs are probably in the yaw area
    • Some strange slewing happening when resetting to GPS
  • Parameter conversion still needs to be done
    • Using gps for alt is quite common
  • We now differentiate the different position sources a lot more
    • E.g. beacon vs external nav
  • Notionally allows velocity to come from one source and position from another?
    • Data tends to come in lumps, so this might not work ATM
    • There are options to indicate what’s fused
      • E.g. xy, xyz and xyz/vel
    • Probably nobody is testing fusing gps position but not velocity
    • Maybe dump velocity for fusing one or the other
      • Just have one parameter
      • Could possibly get position from GPS and velocity from flow?
  • Magcal parameter has been abused to also specify yaw source
    • This will allow us to say, “we want to get yaw from gps” or gsf or external nav…
  • Start to run all autotests on EKF3
    • Currently only 1MB boards default to 3

UTC0018 -

  • User-accessible script parameters?
    • Interim method until we can do parameters properly?
  • Could use SD card instead?
    • Don’t include scripting if you don’t have an SD card ATM….
  • Tridge might not get to doing things properly for quite some time
    • Fix it up before a stable release
    • “Things can change in master”
  • This would remove the pressure to do it properly, ‘though?
  • 2 parameters rather than 4?
  • Scripts get reference to a parameter?
  • Tridge thinks this should go in as-is
  • Reimplement as array, rename then can be merged
    • SCR_USER1

UTC0031 -

  • Will solve a problem with T265
  • Putting the option in uartdriver is not nice
    • Separate bits for send/receive?
  • Needs to wait for Solo testing
    • Separate PR to allow setting of private or not in parameters so you can modify gimbal params

URC0040 -

  • On approach choose between speed and descent methods
  • No way to move between progressive and full crow
  • Set it up so on a switch you can move between no, progressive and crow
  • Progressive by setting the bit or setting the switch up
  • Need to fix the dspoiler thing
    • Can be merged after dspoiler fix
    • More testing

UTC0047 -

  • We previously asked, “What flight modes does this apply to?”
    • Auto / Landing?
    • Should be correct now
  • Do we want this on in fbwa?
  • Manual mode?
    • Qstab -> manual should stop the vertical motors immediately
      • Safety thing
  • Qhover does support throttle suppression
    • Don’t want to go to spin-min or stabilize, which would be bad?
    • How does this work in Copter?
    • Arm in althold with zero throttle, does it stabilize instantly?
      • Airmode only affects manual-throttle modes
    • is_vtol_manual_throttle() on the flightmode
    • Fbwa is effectively althold vertically but manual throttle
    • No behaviour change if we don’t have a strong reason to do so

UTC0101 -

  • Mission restart fix is in
  • Vtol auto missions were broken
    • Not setting a horizontal speed
    • Auto transition to landing would have a left-over setting and things would work there
  • Still waiting on compass fix from Sid
    • MO thinks this is OK
    • Doing it at end of compass cal?
      • Is that a good place to do it?
      • End of compass cal means that if your 3rd compass was excluded because you swapped out a compass then it won’t do that third compass
        • Won’t fix things for the third compass
    • There’s a “remove missing” button now in MP

UC0103 - not much to mention for Copter-4.0.4

UTC0106 - not much to mention for Rover

  • Not for a while
    • Probably a 4.1

UTC0109 - close

1 Like