CraigElder
(Craig Elder)
2
Attendee count (max): 24
UTC23:03 - generic; EKF2 attitude diverging on boot
- Was happening on Chibios on SkyViper
- More likely to happen on a linux-based board with less-well-defined timing
- Attitude diverges even though vehicle is level
- 30 degrees or even 130 degrees
- Sometimes it recovers, sometimes stays crazy
- Seen this before on things like PixHawks
- EKF2 has a vulnerability to small timing issues during initialisation
- First sensor sample it gets out of buffer it uses 26 times!
- If that value is bad then things can be bad
- Fix seems to fix the problem
- But doesn’t seem to be able to entirely explain the problem
- Has anybody else seen this behaviour
- Timing is tight
- EK2 has to have a large-delta sample to play with to trigger it
- Boat mode does exacerbate the problem
- Needs a little gyro bias to happen
- Also moving the vehicle during initiation might happen
- There’s a
#if 0 committed which can help to trigger the bug
- Quite a few days to track this one down
- Gyros still settling is the arming failure
UTC23:08 - Python modelling based on Paul’s matlab script
- Think ecalc - choosing props, batteries, wings etc etc
- Ecalc is a little inaccurate on some vehicle types
- And doesn’t cope with other types at alls (e.g. vectored tailsitters)
- CUAV is using this for the next outback challenge to find something that works
- VTOL electric
- Endurance + speed is hard with batteries
- Previously used petrol…
- Based on this realflight aircraft have been built….
- Open script - look at parameters you can set
- Look for fixed values which should also be parameters!
- A GUI for it?
- A web page for it?
- Default parameters are for a TVBS
- 28m/s for an hour
- Gives you endurance
- Small changes can make big difference to results
- 12S required in the sample case
- Much smaller propellers than initially guessed at 250mm
- MdB: small but fast vs slow and large gets you towards same result thrust… You should be able to make either work
- 100 km/h to 90km/h -> can be 50% more range
- Power laws
- Putting a third motor on (for cruise)
- Greatly increases potential range
- Can be right at the top of the efficiency curve for both forward flight and hover
- Original video was for 700mm props
- New video for 3-motor variant coming
- Variable pitch props?
- Only ones relatively easily available are heli tails
- Not much data available on them
- Mechanically complicated
- Too complicated for CUAV’s available time
- Load prop data in different format?
- “Proppy” project
- Data can come from theoretical models rather than wind-tunnel test
- c.f. university of illinois data which is wind-tunnel data
- So be careful with that data…
- MdB: the crituqe of the DB is that this prop set would drive you towards small fast props over large slow
- Blog post coming
- Javascript version coming, maybe?
UTC23:08 - Randy and Copter
- Spent last week on Rover, so not much to report
- New loiter from Leonard
- Leonard’s got a lot of feedback from heli guys so is working through that
- No significant new changes out of that yet
- Regular loiter wasn’t working well yet, soooo….
- Also some confusion with the L1 controller
- Need multicopter users to test it!
- PB:I’m happy to rebase Leonard’s stuff on top of my mode stuff
- Might release an “alpha” containing the new loiter code
- There’s a SkyViper branch rebased on master
- Could then bring Leonard’s new loiter in
- There’s lots of changes since it was last tested on the SkyViper
- Need to be really, really careful with Loiter as it is so widely used
- Peter’s flight-mode changes
- Like what we have in Rover
- Not pushed in just yet
- Randy wants to move extra functions in
- Peter wanted to get basics in first
- Should be an NFC
- Amilcar: Please merge it
- FF: full support for merging it
UTC23:08 - Randy and Rover
- Acro mode!
- Turn -rate controller + speed
- SmartRTL!
- Channel-7 switch for arm/disarm
- PWM thrust compensation
- Couple of cool PRs to come in
- Inc from Pierre
- New -rc3 coming
- Should be the last one before it goes out
- INS?
- Probably push this one off to another release
- Need to push a release out at some stage after all
- Mixer changes mess up everyone’s steering gains to need to solidify it
- 3.2 works very well
- Randy is very confident
UTC10:46 - mavlink packet capture
- Would be nice to know what mavlink stuff arrived
- And allow trouble-shooting GCS
- Xe2-private format
- Black-box recording of commands sent to flight controller
- For regulations
- MdB: tlog doesn’t tell you much
- NuttX filesystem is a problem for tlog
- Can we use dataflash?
- Variable-size packet a hurdle for dataflash
- TLOG message 250 bytes?
- Includes length/direction?
- Dataflash doesn’t contain all data
- Sometimes tlog contains data that dataflash doesn’t
- Synthetic airspeed wasn’t logged until recently
- PB: Use case the the serial-line-capture was not really for day-to-day use; it was more for diagnostic purposes.
- 99% of incoming data will be worthless
- Heartbeats, stream-rate-setting, …
- Logging serial stream would be a useful thing
- DJI have an internal log that contains all of the commands
- Encrypted by you can decrypt it
- To be able to fly will need something…
- Might suddenly jump up, too
- Our log messages have been bumped up to provide more information
- E.g. adding mode-change-reason
- But we’re not consistent on recording it
- This is something we need to discuss before an issue gets opened
- Trying to determine if a command was received and accepted
- Redo a flight - whether something was commanded or not and by what
- Call it “replay”?
- PB: Let’s not use “Replay” :-P. Maybe “ReFly”?
- Randy: let’s raise an issue and put it on the shelf for a bit
- Most of the rules on the way are going to follow “industry best practices”
- I.e. what the major drone manufacturer does
- Our analysis is far, far better than ArduPilot
- At least for normal users
- Higher-end controllers are actually very, very good on DJI
- NDA required
- Unknown as to whether Chibios is better having multiple files open
- Need to try it
- One-page-cache
UTC11:13 - authorization
- FF doesn’t like it as-is
- Security
- Mavlink signing
- Tom Make it work
- Later enforce signing
- Tridge: we shouldn’t require signing; transport may be secure other than signing
- Tridge: Using command_ack at all seems crazy
- Should be a return message
- Tom: There was originally a message
- Mavlink Crc check doesn’t extend to extensions!
- Do we do our own thing instead?
- Can’t accept this auth stuff without using the extensions
- Command-long like this requires extensions
- Do we want to be compatible
- Systems are already in place to support this for PX4
- Correct is probably to use many mavlink2 messages
- Not use command long
- Why does Command long exist?
- was just convenience
- Intermediate systems can show them as well
- Should we kill the PR and do things properly?
- Fundamental problem that 0 is a valid value for sysid/compid so the targets in command_ack aren’t going to work!
- Command_ack2 with target system/target component
- Protocol capability to indicate you can handle ack2?
- Would need to phase it in
- A specific ack message allows you to put the reason for not being authorized into the message nicely
- Project wing and intel aero need utm trials with NASA using this code
- Along with airmap
- Way forward for this PR: mavlink2 messages
UTC11:40 - mavlink discrepancies
- Don’t try to push our changes up?
- People have had a lot of trouble with PRs just staying open on the uplink repo
- PB: Hang on - how does this work with things like the vehicle type enumerations?!
- Chasing development-of-the-week isn’t useful
- QGC doesn’t complain
- People making apps to work across both systems is a problem
- We didn’t push the dodecahexa stuff upstream
- No release has been done with that version number in there so we can fix it this time
- We can fix this on our end
- Others have released
- Amilcar says try to follow but don’t do stupid things
- If aim is compatibility then having a separate px4 XML would make things a lot worse
- QGC builds against ardupilotmega.xml which includes common.xml
- Run-time-swappable parsers?
- Make more of an effort to ping people on PRs to get stuff upstream
UTC23:52 - google group votes!
UTC23:52 - please review PRs!