Issues & Pull Requests
Plane
Copter
GSOC
1 Like
Attendee count (max): 16
- Fixes Navigator board
- Sub wants a backport
- Been in for master months now
- Tridge nad Randy will discuss when to backport this
- âClarifiesâ get pilot lean angles
- Fixes shape at extremities on the diaganonals
- Now a common library function so quadplane gets same fixes
- Not a critical fix
- merged!
- Move implementation of a method to header
- Loses lots of bytes on MatekF405
- [9:09 AM] Peter Hall: I have seen odd stuff like this before.
- [9:10 AM] Peter Hall: I usualy blame âalignmentâ or something else equally vague.
- RNGFND_MAX_RATE parameter to limit rate at which rangefinder messages are sent on AP_Periph
- 100Hz rangefinder you should be able to look through treesâŚ.
- Do aggregation on the rangefinder?
- So send longest or shortest or average or what from the rangefinder?
- This punts that and the autopilot can do that aggregation
- So send longest or shortest or average or what from the rangefinder?
- 2 bytes of rangefinder is 24 bytes on the DronCAN busâŚ
- Flight-tested on a benewake TF-03
- Fix replay with EK3 source changes
- Merged!
- Auto-set field elevation from origin in baro
- Matches EKF origin
- Aviation altitude more correct
- Should get Ryan to look
- Fixes bad fgets implementation
- Merged
- Fix for the EK3 time horizon buffers
- Currently if the buffer is empty and you recall that element it fails
- Only works if thereâs >1 element in the buffer
- No test suite
- RewrittenâŚ.
- New unit tests written
- Test suite needs looking at and ensuring it is correct
- Other issues:
- Peter will review
- Others really should review
- Symptoms of old behavior:
- Unsure
- Only get half your data?
- EKF IMU buffer also needs looking at!
- Would it hit all lanes at once?
- Do we really need >1 time horizon buffer, one for each core?
- Saves a lot of flash
-
merged before call
-
Lean forward 20 degrees for 5 seconds
-
ATTITUDE_TIME
-
ATTITUDE_RATE_TIME?!
- Auto is âunsupervisedâ
- Leonard reckons anything we do in auto would be âsafeâ, i.e. not going to crash the aircraft
- This current PR is essentially alt-hold
- Wonât reduce altitude
- This current PR is essentially alt-hold
- Leonard reckons anything we do in auto would be âsafeâ, i.e. not going to crash the aircraft
- Auto is âunsupervisedâ
UTC1143 - Plane: stable 4.2.x issues list ¡ Issue #15941 ¡ ArduPilot/ardupilot ¡ GitHub
- Plane 4.2.1
- 4.1 â 4.2
- Q_M_PWM_MIN and MAX both being zero?
- Via param load?
- D-short wonât initialise
- Sometimes only 1 set?!
- Maybe people are auto-correcting it back to what it was before upgrade!?
- I.e. doing a param-diff and trying to âfixâ things
- Copter has a check for it
- Tridge wants to fix automatically
- Tridge will try to reproduce
- Quadplane i-gain/p-gain ratio needs to be checked
- Many people setting i>p which is very bad
- A specific arming check is coming in to catch this. Igain should always be less than your pgain
- In feed-foward i should be feed-forward
- Otherwise i<p!
- Gyrocopter needing really big i-gainâŚ
- That was a feed-forward thing
- Some planes will definitely flip
- PH thinks ânot all planesâ
- Any COG change will be problematic
- Oscillating on IâŚ
- Maybe an option bit to allow i>p?
- Tridge thinks we really do need to be checking parameters for the user
- QP XY gains
- Must keep these in proportion!
- People donât
- We should check them
- Tridge want sto add a pos_xy_mul
- Defaulting to 1
- Leonard not in favor
- This isnât even documented!
- Rate gains in MissionPlanner are done with a single slider
- 10-year-old screen
- Nobody knows what it doesâŚ.
- 10-year-old screen
- Must keep these in proportion!
- Tridge thinks we need to change the way we think about parameters
- Be more careful as to what we allow
- Tridge wants a case before allowing i>p
- Copter with big CG offset
- Big P was problematic
- Bendy vehicle
- Copter with big CG offset
- Fix on GCS?
- Too slow to get it out to embedded QGC on hardware
- New parameter markup, â@Ratioâ?
- To compare against other parameters
- This would break a whole bunch of things?
- They fix their parameters
- We did this with Q_ASSIST_SPEED
- People werenât setting it
- We made people change it to -1
- QP XY gains
- Leonard wants flexibility
- Prearm check skirts the line
- Tridge would add an option bit to allow i>p
- Larger the multicopter i-to-p smaller i term
- As you go smaller you tend to have higher i term
- Potential benefits having i>p
- As you go smaller you tend to have higher i term
- Has been bitten by not allow people to do things, to go into that corner
- I not related to p on CoptersâŚ
- Separate prearm bit for PIDs?
- The âIâm an expertâ prearm bit?
- Current proxy rations are from a discussion with Paul from a long time ago
- No methodical analysis on them
- You might not have to reduce position-p as much as velocity-p
- Single knob might not do it
- Leonard might be OK with the MUL thing⌠makes him throw up a bit in his mouth, but might be able to look awayâŚ.
- We have a lot of configurability
- Not just stupid people making these mistakesâŚ
- Leonard deliberately using colorful language
- People not taking the time and being irresponsible
- âThis is why we see so many aircraft flying like shit and costing lots of moneyâŚ.â
- People not taking the time and being irresponsible
- Need a section on the Wiki for the position controller
- Most Leonard tends to do is divide by 2
- Rarely happens
- Defaults tend to work really well
- Lean agle is acceleration and the rules get very simple
- Very large or very unhealthy multis sometimes need reduction
- Carry-on from issues in the attitude controller
- Unless it is over 100kg you generally donât need to reduce
- Quadplanes are different again, âthough
- If youâre having xy problems your problems are probably further up
UTC0026 - Copter update
-
Copter/Rover: 4.2.0 issues list ¡ Issue #20192 ¡ ArduPilot/ardupilot ¡ GitHub
-
4.2.1rc1 is out in Beta testing
-
Maybe some d-shot fixes?
- But still some reported issues
-
New issues, only one thatâs important
- Lidarlite broken?
- Only on H7?
- 4.1.5 broke too?
- I2c rangefinders in general?
- Callistos are running i2c and theyâre working just fine
- Lidarlite has special i2c handling
- Always been problematic
- Set_split_transfers call
- Fpga on their side implements i2c
- Within the i2c spec, they say
- Every implementor to use the pulsedlight struggled
- Benewake is much easier to work with as a company
- Every implementor to use the pulsedlight struggled
- Within the i2c spec, they say
- Always been problematic
- Lidarlite broken?
-
Missions may complete while vehicle is disarmed?
- Plane has special code to not complete some items e.g. takeoffs
-
Full double-notch?
- Depends on PlaneâŚ.
UTC0040 - Tracker update
- Beta release done!
- Copter Release Procedures â Dev documentation
-
Custom.ardupilot.org
- Can now select a branch to build!
- A little clunkyâŚ.
- Should display which branch youâre building
UTC0045 - GSoC update
- ROS1 rather than ROS2
- Want to do ROS2 but mavros isnât there yet
- Cartographer etc etc for ROS
- Sanket and Shiv are all over things
- PHâs student not so much ATM
- Half our students engagedâŚ.
UTC0047 - partnerâs meeting tomorrow
UTC0047 - close
I just had a thought about the arming checks discussion.
How about a Lua script?
It could include a standard set of parameter value checks, with maybe a flag for each check as to whether itâs a warning or error.
The nice thing about this is that partners (or anyone really) can choose not to use it, or have their own version with customized checks added or removed. It would also not be GCS dependent, errors/warnings could be sent as standard GCS text messages.
1 Like
I had a go at implementing this. This is a DRAFT PR for comment/suggestions.
1 Like