Dev Call Feb 11 2019 2300 UTC

Issues & Pull Requests

  • compass switching bug in EKF
  • Scripting

Release Update



Funding Committee

  • Partner Renewals

Attendee count (max): 26

UTC1107 -

  • Singleton refactor

  • Try to get commonality between implementations

  • Should we really be using macros

  • Tridge likes the concept of a cleanup

  • Should we have a singleton class things inherit from?

  • Tridge: We should just panic on duplicates

  • Would be nice to get rid of the copy constructors at the same time

  • Have some separate class which returns the singleton and use templates for it

  • Stackexchange has a whole bunch of stuff on inheritance and singletons

    • Type safety is a must
  • There would be several macros involved

  • General agreement on “need a cleanup”, so that’s good!

  • More investigation required

UTC1107 -

  • Tridge: yes please!

  • Make sure this is working on all platforms

  • No objections

UTC1117 -

  • Tridge has looked at this and it doesn’t look quite right

  • Needs to update body_dcm_matrix

UTC1122 -

  • Stop making every servo function have a different variable have some sort of bitmask

    • Enable different types on same pin
  • Allow servo type mask to override pin settings

    • Allows boolean and analogue outs (w/low-pass)
  • Currently every library has to tweak the output type itself

  • Tridge wants to see the arming check that what’s been requested is actually possible

    • E.g. throttle and flaps on the same timer is a very bad thing

      • As in flames bad thing
    • Make checks before enabling outputs

    • Only checks configured outputs not what’s actually on there

    • RC_SPEED, servo_blh etc etc parameters are all involved and imply a certain frequency to go to each output

      • Right now you can set up a combination where bad things happen

      • D-shot wins

      • We can check for contradictions

      • Need these checks before we add more flexibility

    • We would probably fail arming until people fix their configurations

    • New HAL function which asks for the output grouping

      • Should the hwdefs define groups?

        • Defined by timers

        • Two sets of timers, on some autopilots, IO and FMU groups

      • Servo rate per group?

      • Helis try to do higher rates on their swash gimbals vs camera gimbals

  • Each feature e.g. mount requests a minimum rate?

    • check if that can’t be supplied

    • Do we want mount to know about all the different sorts of servos?

  • Again, no outputs until validation is done

  • Maybe force safety on if there is a configuration issue

  • Rerun validator every time we call set_frequency and refuse if it is not possible

  • Need to be able to validate on the ground using SITL

    • So do third part first
  • Doing stuff per-servo?

    • D-shot / 1-shot is currently one parameter

    • If we were to do per-servo then Copter setup would need to set up n parameters

    • SERVOx_TYPE?

      • 8 parameters to set

      • We already have MOT_PWM_MIN and MOT_PWM_MAX

      • Deliberate decision to not allow flexibility on these sorts of things

      • One-shot on four of your motors and non-one-shot on other outputs is not supported

      • Maximum flexibility

        • But also maximum chance to screw things up
      • We tell people to use the same motors and escs

        • People already don’t (different props etc)

        • Fast forward motor?

      • [10:49 AM] (Channel) Naterater: I don’t that’s so difficult if we explain what output output groups are… and we should be doing that more now.

      • Nobody has asked

      • Quadplane does allow you to be versatile on forward prop vs vertical props

      • Motorsmatrix must all be the same

      • Flexibility has a cost

        • Poor tuning / bizarre tuning
      • TP: SERVOx_TYPE is brain-dead obvoious.

      • [10:51 AM] (Channel) TP: allows for mis-configuration, but that can be checked

      • [10:51 AM] (Channel) Naterater: But it implies that you can set it per channle… and you can’t

      • [10:52 AM] (Channel) Naterater: you can only set one type per group of outputs (as I understand it)

      • [10:52 AM] (Channel) TP: but the groups change on different hardware

      • [10:52 AM] (Channel) TP: abd that’s “magical” to other users

      • [10:52 AM] (Channel) Naterater: Yes, and that needs to be noted in the parameter description.

      • We use specific mappings for Copter to fix the PixHawk groupings

        • Other flightboards don’t actually give the same timers on those pins…
      • Tridge: Need a plausible vehicle which would benefit from the flexibility SERVOx_TYPE would allow

        • [10:54 AM] (Channel) Naterater: I need 4 servos at high rate (flight control survaces). I also have some cheaper analog servos for internal doors. I also have BLHeli DSHOT outputs, and I have relays.

        • Naterater: This could get rid of the BRD_PWM_TYPE parameter too.

      • MdB: Breaks most/all of the current setups? By the time you are done the upgrade path you have the code to do the checks…

      • [10:55 AM] To Weekly devcall: By the time we require the GCS to have a "motor solver", we have probably gone too far :slight_smile:

      • There are some flight boards out there that have 16 groups!

      • You can have two different output types on the one pin so long as they’re the same frequency

      • E.g. oneshot125 and pwm

      • We ignore the sevo min and servo max stuff in Copter

      • Firmware upgrade is going to be problematic

        • MOT_PWM_TYPE would go away
  • Internal error checking first!

UTC1159 -

  • Two different failure conditions for quadplane takeoff

    • Timer expires moves you to qland

    • Airspeed sensor moves you to qland if you’re not going to be able to make progress

  • Problem caught with deceleration in takeoff

  • Originally a parameter for timing

    • Didn’t work well for different takeoff scenarios
  • Vtol takeoff when already flying case is hairy

    • Starting with velz of zero is reasonable
  • Tridge likes it

  • Needs more testing

  • Set a default instead of not enabling?

    • Set it conservatively

    • 200% or 300% maybe 500%

    • Linear scaler on time

    • Default off for the time being, maybe non-zero in the future

  • Can be merged when MdB is happy

  • Typo spotted!

UTC0007 - scripting

  • Scripting bindings generated and committed vs generated every time?

  • We don’t rebuild IO firmware every time

  • Generator is currently Closure

    • Will probably need to be in Python
  • Edn file input format

  • Lon, lng and long!

  • Better without renames?

UTC0011 -

  • Reviewed this-morning

  • Tridge is happy for this to go in after it’s been appropriately tested

UTC0015 -

  • Do a beta today

  • Merge this PR today too

UTC0020 -

  • Tridge is happy with this

  • Randy is happy to move the send text into the library

  • And reorder the send-text vs enabled in the library

UTC0028 -

  • No movement since last week

UTC0028 -

  • New frame types have gone into master

  • Need to set correct default frame type

    • Tom!
  • One additional line to get the frame type correct (betacopter frame type on this vehicle)

UTC0030 -

  • Touches a lot of stuff

  • Peter to review

  • Randy is concerned about iterm buildup

  • In Copter the motors handle the stop

  • Does this cope with CAN outputs?

    • Copter motors does

    • Tridge thinks this will work correctly on voltz etc

      • Can test by putting sbus output on a telemetry port and put a breakpoint in
  • Randy’s not keen

    • Putting logic into servo library rather than motors doesn’t seem correct

      • Spreading logic out
    • Would prefer to have Plane get a motors library

      • Plane has a stop everything at top level

        • And iampete used that
  • “Is this function producing dangerous output?” new method

    • Bitmask?

    • Boost throttle?

    • Starter motors?

    • Don’t want knowledge of ICE starter motors in AP_Motors

    • Could be a relay?!

    • hal.util->get_soft_armed() but for estopped?

  • Nate doesn’t like “emergency stopped” as a name

  • Stop outputs to landing gear?

  • How about parachute?

  • Estop no longer means “can’t be instantly restarted” - it has changed over time and now comes down to safety case

  • RC option to enable/disable safety might be what Nate is after

  • Leonard’s i-term buildup feature relevant?

UTC0047 -

  • Merged!

UTC0049 -

  • FF is keen

  • MdB is looking at it

  • CHUTE_CRIT_SINKRATE non-zero means trigger?

    • Get rid of enable parameter

UTC0056 -

  • AC_LOITER configurable waypoint speed

  • Remove devcalltopic?

  • Feedback from user needs looking at

  • Randy has reservations about this solution and will look at it

UTC0056 -

  • Tridge: We should treat 0,0 as an invalid location

  • We do have a bug with missions crossing the dateline

  • Distances between points crossing dateline (or equator?)

  • We should add an autotest and bypass it using the skipped-tests

UTC0103 -

  • Needs to be reworked as it has conflicted

  • Some debate as to whether it’s correct or not

  • Probably needs Paul to validate the EKF changes are still good

UTC0106 - compass bug fix

  • Did not fail over compasses correctly if bad innovations if you have 3 compasses

  • New Copter beta out 3.6.6.rc2

    • Final on Friday maybe
  • New Rover release later this week

  • Plane beta coming

UTC0107 - ROS object avoidance

UTC0110 - Copter and Rover


  • 3.6.6rc2 out and being tested

  • Couple of things

  • Which vehicle, which firmware and which autopilot?

  • Corrado’s fly-away

    • Determined bad GPS fix / interference

    • Plan on improving the EKF failsafe

    • compass/position/velocity innovations didn’t get high enough fast enough

    • Usually compass fails, but it didn’t in this case

    • Velocity innovations off-the-charts

    • Change EKF failsafe such that if velocity innovations are terrible we trigger regardless of the position innovations

  • Rover 3.5.0 out last week

  • 3.5.1rc1 out this week

    • With gripper and EKF fix

    • D-shot isn’t actually working

    • Blheli works

    • Dshot output doesn’t seem to work

    • Regular PWMs

UTC0115 - tridge and Plane

  • Incorporate all of the stuff Randy’s putting in Copter into Beta later this week

  • Tom is looking at adding sink rate to loiter-to-alt

    • Instead of using TECS
  • Maybe use DO_CHANGE_SPEED instead?


  • Mission storage?

UTC0118 - vtol landing?

  • Mdb, do you still want to handle that?

  • PR marked as devcall for next week