Issues & Pull Requests
- compass switching bug in EKF
- Partner Renewals
Issues & Pull Requests
Attendee count (max): 26
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
There would be several macros involved
General agreement on “need a cleanup”, so that’s good!
More investigation required
Tridge: yes please!
Make sure this is working on all platforms
Tridge has looked at this and it doesn’t look quite right
Needs to update body_dcm_matrix
Stop making every servo function have a different variable have some sort of bitmask
Allow servo type mask to override pin settings
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
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
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
Mid-air reboots would be even more complicated
screwed because you don’t get servo outputs until gyro stabilizes.
We should look at this
Can’t turn it off until valid
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
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
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
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
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
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
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
Internal error checking first!
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
Vtol takeoff when already flying case is hairy
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
UTC0007 - scripting
Scripting bindings generated and committed vs generated every time?
We don’t rebuild IO firmware every time
Generator is currently Closure
Edn file input format
Has to match our structure names
Lon, lng and long!
Better without renames?
Tridge is happy for this to go in after it’s been appropriately tested
Do a beta today
Merge this PR today too
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
New frame types have gone into master
Need to set correct default frame type
One additional line to get the frame type correct (betacopter frame type on this vehicle)
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
Randy’s not keen
Putting logic into servo library rather than motors doesn’t seem correct
Would prefer to have Plane get a motors library
Plane has a stop everything at top level
“Is this function producing dangerous output?” new method
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?
FF is keen
MdB is looking at it
CHUTE_CRIT_SINKRATE non-zero means trigger?
AC_LOITER configurable waypoint speed
Feedback from user needs looking at
Randy has reservations about this solution and will look at it
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
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
New Rover release later this week
Plane beta coming
UTC0107 - ROS object avoidance
Jaime was first to do it and helped Randy do and document
Working well, if not as smoothly as Jaime’s
UTC0110 - Copter and Rover
3.6.6rc2 out and being tested
Couple of things
Luis said Graupner RC protocol isn’t working (sumd?)
Which vehicle, which firmware and which autopilot?
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
Dshot output doesn’t seem to work
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
Maybe use DO_CHANGE_SPEED instead?
UTC0118 - vtol landing?
Mdb, do you still want to handle that?
PR marked as devcall for next week