Attendee count (max): 18
- Direct drive tail rotors
- PH had made some suggestions on minimising impact on other vehicles
- Parameters in higher-level table but also in lower-level table?
- One variable in two tables?!
- Depth becomes an issue
-
#define out the table for multi-copter
- Group info pointer or varptr?
- Can’t do a subclass (like we do for attitude controller) as we’re in the library code
- Heli ones exist in the subclass
- PH and Bill will work on something around #ifdef’ing out the code
- Dual aircraft synchronised aerobatics
- Only contention is timing
- Should we use 64-bit numbers?
- We use 32-bit numbers ATM in LUA, even though most of the time it’s 64
- There’s another PR to allow for 64-bit numbers
- Allows for time since 1970 (or GPS epoch)
- Time-since-boot in millis gets worse as you go along in LUA as floating point precision degrades
- Uint32_t is horrendously slow in LUA
- Double-precision would be much faster on H7
- Surprisingly no more RAM usage for double
- LUA aligning to 8-byte boundaries?!
- 17kB to go to 64-bit
- Exp and pow
- But EKF3 uses double maths
- We use single-precisions of these in EKF3
- Position controller uses 64-bit arithmetic in many places
- F4 is single-precision for LUA
- Tridge doesn’t want to do 64-bit integers and not 64-bit floats
- Uint64_t same as we do our uint32_t?
- Using GPS bindings has a race
- 200ms granularity
- 3 calls
- Use time of last fix to get a global time
- Lots of bindings to get 64-bit
- Fewest code is existing approach to return a tuple
- Many places doing millis*0.001 which is bad
- Anything doing distances is bad across long distances in scripting
- Same reason we went to 64-bit maths in position controller
- Scripting on F4 is simply not a reasonable thing to do?
- Check the return values and magically make the bindings 64-bit?
- [9:26 AM]Tim Tuxworth: You can’t even build scripting into an F4.
- [9:26 AM]Tim Tuxworth: It doesn’t work
- [9:28 AM]Tim Tuxworth: If you savagely drop almost all other functionality you might get scripting to build if you are very lucky.
- [9:30 AM]rmackay9: I’d say scripting doesn’t work on F4 so don’t make any special changes for it
- PH will look later in the week
- Luminousbee5 compilation problem
- Maybe just change this to use the same clock tree as CubeOrange?
- Try deleting the assert and see if it is only the one clock which is faulty?
- Put the pinout into CubeMX
- Peter and tridge will try to sit down with CubeMX later today and nut it out
- Fix for RPi in hte linux HAL
- Now uses files to determine base
- Want bluerobotics input
- Add radix2hd board
- Closed base bootloader
- Needs some documentation
- And splitting
- Backport?
- Would need to show the external flash optimisations didn’t affect anything without external flash
- Implement user-defined angle-limits
- If you point using ROI then the limits aren’t honoured
- Setting min and max to zero should disable yaw
- Complicated by the fact the limits are in body frame
- Might have some oddities at extremes
- Gimbal can get confused at limits
- Copter update
- Beta went out
- Some issues did come up
- Want beta builds on the custom build server
- RPLidar not working
- just treat the startup string ignored?
- Not a regression
- Gremsy WRE not working
- Rover autotune went out for testing
- Script
- 4.3 never went out the door for stable
- Once Rover autotune is working there’s still a couple of issues to make a 4.4
- SCurves doesn’t respect the turn radius of the Rover
- Long boat with a long turning radius?
- SCurves doesn’t care
- Overshoots the corners
- Need to modify SCurves so the planned path takes into account the turning radius
- I-term build-up if the vehicle can’t keep up or ovre-speeds
- PSC
- Zero out position i-term in forward/back direction
- Corner accel parameter can only ead to corners being cut less, so nota solution
- Tidy notify defines
- Merged!
- Deprecation really doesn’t help - nobody reads the output
- DEFAULTGPIO
- Avoid ESD problems
- pull-downs on all pins to avoid it
- But you don’t want to do this without hinking as you cause current draw
- Which is worse?
- ESD issues or current draw?
- Defaultgpio applies to all pins which aren’t otherwise used…
- Tridge thinks we should make it work regardless of location in the file
- Minimise vulnerability to ESD MCU
- Add a bitmask to disable mode change from GCS for specific modes
- Longer-term solution is to fix the GCS
- Too basic a feature to go into scripting?
UTC 0050 Plane: stable 4.4.x issues list · Issue #15941 · ArduPilot/ardupilot · GitHub
UTC0100 AP_GPS: fixed ublox M10S auto-config by tridge · Pull Request #24035 · ArduPilot/ardupilot · GitHub
- M10 does not follow datasheet
- May need to be backported to 4.4
UTC 0105 Reload defaults file at end of AP_Vehicle::setup by peterbarker · Pull Request #24007 · ArduPilot/ardupilot · GitHub
UTC0125 AP_SerialManager: provide informative error if requested protocol is not enabled or is a duplicate by andyp1per · Pull Request #24026 · ArduPilot/ardupilot · GitHub