CraigElder
August 26, 2019, 11:00pm
1
GSOC
Issues & Pull Requests
opened 02:25PM - 23 Jun 19 UTC
closed 11:35PM - 25 Aug 19 UTC
BUG
Copter
Safety
Solo
### Bug report
There are now at least three different people with 4 differentā¦ Solos running 3.7-dev that have had ArduCopter crash and stop in flight.
- The dataflash and telemetry end abruptly with seemingly no problem logged.
- The motors stop. The copter falls to the ground (obviously).
- There are no sounds, beeps, or indications. It just stops and drops.
- Upon repowering, everything starts up like normal.
- I have an incident that took place before the watchdog even existed. And three more post watchdog.
- In the all cases, the version of Copter master (3.7-dev) was about a month or more old from now, so probably just before and just after watchdog was implemented (for time reference).
Thus Far, it has not happened to anyone using the Green Cube. And to my knowledge it hasn't happened to anyone else running any other hardware. _It appears to be isolated to the old 3DR manufactured Pixhawk 2 for the Solo_.
I've put the latest master from yesterday up for users to install since I think it has some better logging. And hoping some users will be willing to test it knowing their Solo could still crash at anytime.
This appears to be what happened back in this issue that at the time seemed like a watchdog issue. As it turns out, it was the watchdog doing its job. (https://github.com/ArduPilot/ardupilot/issues/11296)
This is a video from a tablet that was screen recording at the time of the incident. It shows that the video stream, wifi link, and companion computer were still powered up and running, despite the autopilot failing. https://www.youtube.com/watch?v=a96sfrEvaWY&feature=youtu.be&t=141. This corresponds to log # 4 in the pre enhanced logging zip file.
**Version**
ArduCopter master 3.7-dev
**Platform**
[ ] All
[ ] AntennaTracker
[X] Copter
[ ] Plane
[ ] Rover
[ ] Submarine
**Airframe type**
3DR Solo
**Hardware type**
Pixhawk 2 cube that is OEM on the Solo. But this is really no different than any other pixhawk 2 hardware on any other vehicle. Vehicles with this failure as far as we know all were equipped with the Solo gimbal.
**Logs**
This first zip is 4 different logs from _before the new enhanced logging._ One of these incidents happened with Watchdog enabled. The others were either before the watchdog or with it disabled.
[Solo.Shutdown.Logs.Before.New.Logging.zip](https://github.com/ArduPilot/ardupilot/files/3323334/Solo.Shutdown.Logs.Before.New.Logging.zip)
Once we get logs using the new logs, I'll put them below.
http://www.chibios.com/forum/viewtopic.php?f=35&t=5198&p=36118#p36118
opened 02:25PM - 26 Aug 19 UTC
closed 09:22PM - 15 Aug 21 UTC
BUG
AllVehicles
SITL
### Bug report
**Issue details**
I'm debugging a stall -on loiter/turns- bā¦ ug found on ArduPlane master.
I'm reproducing the bug using SITL, while doing so I found another SITL bug using `git bisect`.
When on loiter plane suddenly have very bad attitude, I've attached 2 log files, one showing the bug caused by commit a84af856896980e90ecee08ca541bc005c97cf1a . Another one with my patch applied
Here is the patch:
```
diff --git a/libraries/AP_InertialSensor/AP_InertialSensor_SITL.cpp b/libraries/AP_InertialSensor/AP_InertialSensor_SITL.cpp
index f187723d71..4f830ef56d 100644
--- a/libraries/AP_InertialSensor/AP_InertialSensor_SITL.cpp
+++ b/libraries/AP_InertialSensor/AP_InertialSensor_SITL.cpp
@@ -118,7 +118,7 @@ void AP_InertialSensor_SITL::generate_accel(uint8_t instance)
uint8_t nsamples = enable_fast_sampling(accel_instance[instance])?4:1;
for (uint8_t i=0; i<nsamples; i++) {
- _notify_new_accel_raw_sample(accel_instance[instance], accel);
+ _notify_new_accel_raw_sample(accel_instance[instance], accel, AP_HAL::micros64());
}
}
@@ -163,7 +163,7 @@ void AP_InertialSensor_SITL::generate_gyro(uint8_t instance)
uint8_t nsamples = enable_fast_sampling(gyro_instance[instance])?8:1;
for (uint8_t i=0; i<nsamples; i++) {
- _notify_new_gyro_raw_sample(gyro_instance[instance], gyro);
+ _notify_new_gyro_raw_sample(gyro_instance[instance], gyro, AP_HAL::micros64());
}
}
```
The bug is reproducible with xplane on more than 90% of trials within the 1st two loiter rounds.
**NOTE: I'm pretty sure that there is a similar issue with real vehicles on master, but I don't know how can I prove that. Maybe the same exact problem or another problem with inertial sensors recent changes, so I hope you investigate this too.**
**Version**
master bisected at commit a84af856896980e90ecee08ca541bc005c97cf1a
**Platform**
[ ] All
[ ] AntennaTracker
[ ] Copter
[ x ] Plane
[ ] Rover
[ ] Submarine
**Logs**
_Please provide a link to any relevant logs that show the issue_
[attitudelossbug.zip](https://github.com/ArduPilot/ardupilot/files/3541531/attitudelossbug.zip)
The logs are run at the bad commit not on master.
ArduPilot:master ā peterbarker:pr/display-buffer-issue
opened 01:11AM - 24 Aug 19 UTC
We index into these arrays so ensuring their size is worthwhile
ArduPilot:master ā peterbarker:pr/log-mavlink-commands
opened 01:24AM - 23 Aug 19 UTC
ArduPilot:master ā WickedShell:wickedshell/ublox-log-first-uptime
opened 08:30PM - 21 Aug 19 UTC
By logging the uptime when we first detect the instance (really it's when we getā¦ the first NAV-STATUS from the GPS), this lets us tell if later redetects of the GPS are a reboot of the receiver (IE power issues) or cabling issues that cost us communication with the receiver. This was motivated by the uncertainty we always have when reviewing logs, and came up again [here](https://discuss.cubepilot.org/t/loss-of-all-satellites-on-here-2-gnss-in-flight/1570).
The alternate logging option would be to always log the GPS uptime which would be more robust if the GPS reboot on the same configuration/baud rate, I rejected this however as it requires us to never turn off the NAV-STATUS message, which increases the bandwidth required to the receiver. If we are all fine with the extra comms to the GPS and logging we could get this information brought down as well.
EDIT: This was bench tested against a F9P as it happens to be what I have plugged in.
ArduPilot:master ā peterbarker:pr/sub-format-warning-fix
opened 09:47AM - 21 Aug 19 UTC
```
../../ArduSub/commands_logic.cpp: In member function 'void Sub::do_nav_delaā¦ y(const AP_Mission::Mission_Command&)':
../../ArduSub/commands_logic.cpp:485:84: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
gcs().send_text(MAV_SEVERITY_INFO, "Delaying %u sec",nav_delay_time_max_ms/1000);
^
```
This was mini-pix as the target.
ArduPilot:master ā peterbarker:pr/copter-fix-drift-disable-compilation
opened 04:02AM - 21 Aug 19 UTC
I have only validated that this compiles.
This should be NFC (apart from actuā¦ ally compiling...).
I think there's a wider discussion to be had on when we should allow these mode switches. Depending on how aggressively it is tuned, popping the vehicle into several other modes may cause it to leap off the ground here.
e.g.:
```
STABILIZE> mode guided
STABILIZE> Got MAVLink msg: COMMAND_ACK {command : 11, result : 0}
GUIDED> Mode GUIDED
rc 3 2000
GUIDED> param set FS_GCS_ENABLE 0
GUIDED> arm throttle
GUIDED> APM: Arming motors
Got MAVLink msg: COMMAND_ACK {command : 400, result : 0}
ARMED
GUIDED> mode loiter
GUIDED> Got MAVLink msg: COMMAND_ACK {command : 11, result : 0}
LOITER> Mode LOITER
APM: EKF2 IMU0 in-flight yaw alignment complete
APM: EKF2 IMU1 in-flight yaw alignment complete
height 15
height 25
SIM_VEHICLE: Keyboard Interrupt received ...
SIM_VEHICLE: Killing tasks
```
ArduPilot:master ā WickedShell:wickedshell/scripting-hard-dep
opened 12:21AM - 21 Aug 19 UTC
Scripting has a hard requirement on AP_Terrain being available, this allows us tā¦ o emit a cleaner error message if you have disabled terrain but not scripting.
This replaces #12065.
If you disable terrain but not scripting you now get a message that looks like this:
```
[530/598] Compiling libraries/AP_Terrain/AP_Terrain.cpp
[531/598] Compiling libraries/AP_Scripting/lua_scripts.cpp
[532/598] Compiling libraries/AP_Scripting/lua_bindings.cpp
In file included from ../../libraries/AP_Scripting/lua_scripts.cpp:29:0:
../../libraries/AP_Scripting/lua_generated_bindings.h:18:4: error: #error Scripting requires terrain to be available
#error Scripting requires terrain to be available
^~~~~
compilation terminated due to -Wfatal-errors.
In file included from ../../libraries/AP_Scripting/lua_bindings.cpp:8:0:
../../libraries/AP_Scripting/lua_generated_bindings.h:18:4: error: #error Scripting requires terrain to be available
#error Scripting requires terrain to be available
^~~~~
compilation terminated due to -Wfatal-errors.
```
EDIT: This was done as a generator feature in the end, as it's where we currently tweak the dependencies, and it allows us to easily add others.
ArduPilot:master ā bnsgeyer:pr-rsc-params
opened 06:00PM - 18 Aug 19 UTC
This PR cleans up MotorsHeli by pulling the Rotor Speed Controller (RSC) parametā¦ ers into the RSC library. Many of the parameters that are pushed to the main rotor RSC are now contained within the RSC and removes many lines within each frame that served to set variables that are properties of the RSC. Two parameters (RSC_SETPOINT and RSC_TYPE) are still passed into the library but the parameters themselves still remain contained within the library. this is necessary to control when users are allowed to change these parameters.
It was discovered during testing that the setpoint would change while the aircraft was armed if user tried changing the RSC_TYPE between passthrough and setpoint types. Changing the type was denied while armed but the setpoint was still changing to the value for the rsc type requested. This bug was fixed
This PR changes the scale of the CRITICAL, IDLE_OUTPUT, and SETPOINT parameters from PWM to %. The parameters are automatically scaled on upgrade to 3.7. Also Prearm messages were added to tell user if these parameters are out of range.
Lastly this PR added more language to parameter descriptions to help the user understand more about the impact of the particular parameter.
This PR has gone through extensive functional checks in the SITL environment to ensure functionality has not been impacted.
@ChristopherOlson if able would appreciate your help verifying that the changes didn't impact the governor functionality
ArduPilot:master ā gediminasgu:auto-mounts-rectract
opened 10:44AM - 14 Aug 19 UTC
ArduPilot:master ā tridge:pr-ap-filesystem
opened 11:12PM - 01 Aug 19 UTC
This adds an AP_FIlesystem API for all filesystem operations. It cleans up the eā¦ xisting posix abstraction in ChibiOS, and will enable us to add automatic remount on operation failures
A new parameter LOG_FILE_TIMEOUT is added which gives the timeout in seconds for log writes. Setting this to 30 allows you to remove the card for 30s and when re-inserted logging will continue.
This is an alternative to #8639 from @peterbarker
Issues:
- [x] adds about 1.7k to flash for unknown reason (fixed, is now smaller than master)
- [x] add automatic remount on IO error
opened 01:21AM - 23 May 19 UTC
closed 02:34AM - 27 Aug 19 UTC
BUG
Library
Solo
### Bug report
**Issue details**
In master chibios, the Solo gimbal's tilt conā¦ trol is overshooting badly.
On the old FW, you can see the gimbal's EKF and target are in lock-step with eachother. And you can see the rate controller smoothly comes in and out as it should in time with the the gimbal tilt reaching its target. _It also continues to work correctly on 3.6 stable Nuttx_.
On master ChibiOS, you can see the target and EKF are no longer on the same page. And you can see the rate controller is overshooting along with the EKF. The gimbal is performing as the EKF and rate control indicate, overshooting its target and then coming back to it.
Things I have already tried while also discussing with JC:
- DMA_NOSHARE on the serial 4 UART
- Undoing the private mavlink channel patch
- Undoing the HAVE_PAYLOAD_SPACE patch
I don't see any commits between 3.6 and now in the mount library that would do this. The only functional difference is Nuttx vs ChibiOS that I can see. Unless it is somewhere else in AP. Logs attached below.
As a hack, I found that derating the rate output by 75% slows it down enough to work properly. But this is obviously not a solution. However it demonstrates that somewhere along the line, the EKF is 75% ahead of where it should be. Or something like that. IDK.
**Version**
Copter 3.7-dev
**Platform**
[X] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine
**Airframe type**
N/A
**Hardware type**
Cube
**Logs**
[Solo Gimbal Logs.zip](https://github.com/ArduPilot/ardupilot/files/3209921/Solo.Gimbal.Logs.zip)
ArduPilot:master ā tridge:AP-Periph
opened 05:26AM - 15 Dec 18 UTC
This is a firmware CAN peripherals. Supported boards:
- 128k flash UC4H boarā¦ d from jDrones (f103 based)
- mRo CAN GPS
- CUAV CAN GPS
Many thanks to @pkocmoud and @jpkh for hardware and pinout assistance, and CUAV for hardware
To build for the f103 use:
- ./waf configure --board f103-periph
- ./waf AP_Periph
to build for the CUAV_GPS use:
- ./waf configure --board CUAV_GPS
- ./waf AP_Periph
to flash bootloader use:
- st-flash write Tools/bootloaders/f103-periph_bl.bin 0x08000000
or
- st-flash write Tools/bootloaders/CUAV_GPS_bl.bin 0x08000000
to flash main fw use:
- st-flash write build/f103-periph/bin/AP_Periph.bin 0x8006000
or flash with the STM32 link utility on windows, at offset 0x8006000, or flash with uavcan_gui_tool fw update
milestones:
- [x] flashes a LED
- [x] UART writes
- [x] can dynamic node allocation
- [x] can node info response
- [x] can bootloader and can fw update
- [x] pin to hold to stay in bootloader (using PB6, the I2C1_SCL pin)
- [x] remote I2C over CAN
- [x] node restart
- [ ] detect node ID conflicts
- [ ] smarter default node ID
- [ ] handle RTCM injection
- [ ] support PPK via RXM RAW logging to FMU
- [ ] add hardware can message filtering
ArduPilot:master ā muramura:AP_Baro_healty_check
opened 06:12PM - 07 Oct 18 UTC
I saw a healthy message with a disarm in the test of the atmospheric pressure seā¦ nsor. I have not found a soft reset on the device with barometric pressure sensor MPL3115A2 if it is equivalent for 2 seconds. I think that it is better to process the judgment to detect the inherent device fault with that device class.
ArduPilot:master ā Jaaaky:pr-auto_mission_better_watchdog_restore
opened 08:58AM - 25 Aug 19 UTC
This allows to run any commands following the last nav_waypoint
that may be reqā¦ uired or change flight behavior for following wps
Plane
The final release of 3.9.10 is now out. Thanks for the test reports!
Copter**
ArduPilot:master ā Jaaaky:pr-auto_mission_better_watchdog_restore
opened 08:58AM - 25 Aug 19 UTC
This allows to run any commands following the last nav_waypoint
that may be reqā¦ uired or change flight behavior for following wps
Rover
opened 06:32AM - 26 Jan 19 UTC
closed 01:00AM - 15 Oct 19 UTC
Rover
This is a list of issues to investigate for the Rover-3.5.0 release:
- OneShoā¦ t (and possibly other output types) not working. Raised by Nando here: https://discuss.ardupilot.org/t/rover-3-5-0-rc2-is-available-for-beta-testing/37731/12
Resolved:
- Build server hasn't rebuilt for fmuv2 (fmuv3 is available here: http://firmware.ardupilot.org/Rover/beta/fmuv2). report is here: https://discuss.ardupilot.org/t/rover-3-5-0-rc2-is-available-for-beta-testing/37731/14
1 Like
CraigElder
August 27, 2019, 2:41pm
2
Attendee count (max): 26
UTC2304 - GSoC update
MAVProxy
Added several small PRS
Really useful stuff
Working on showing arbitrary expressions in the console
Nice blog post acting as final report
AirSim
Really nice report
PRs for AirSim and ArduPilot have been merged
Next stable build of AirSim will have ArduPilot support by default
With nice urban environment
Huge step forward, nice bit of work
Needs some testing under Windows, particularly with object avoidance and the like
Great work from both devs on MAVProxy and AirSim
Both planning on a little work after the period
Matt and autorotation
Pete Hall
Path planning stuff is working now
Tacking on geofence is in
Blog post coming
Lidar on sailboats to not bump into things
pp: --UPDATE ā Thien has completed GCSoC on T265 last week , 3 wikis have been created and all PR have been merged. The experiment are still going on both indoor and outdoor
UTC2314 - https://github.com/ArduPilot/ardupilot/issues/11642
Solos locking up in flight
Interrupt storm theory seemed to be supported by evidence
Added storm prevention into ChibiOS
Limits number of interrupts to 6 per byte
Resets peripheral completely
Tried on Solo, instantly failed
Unacknowledged interrupt (BTF)
write/read on smbus peripheral
After it sends register address and waiting for ack we get constant interrupts
Continues until we get the ack
130acks/4 for byte transfer
If the smart battery never acknowledges then the CPU spends time on interrupt stuff and can fall out of sky
Interrupt happens when going from dma write to dma read
Will not switch to read until ack is received for the initial byte
Storm prevention is mitigation
Acknowledging interrupt is fix
Could notionally happen on any i2c device
http://www.chibios.com/forum/viewtopic.php?f=35&t=5198&p=36118#p36118
Why not before?
Probably timing
Previously we didnāt have watchdog support so we put it down to power failure
With watchdog we can definitively say it was a CPU lockup
So it may have been happening before but we couldnāt attribute it to a software failure
No instances for 6 weeks
Rare bug to start with
Still not completely satisfactory
Could be changes to battery monitoring stuff?
Triggers particularly on 10-byte transfer
When we first turn on the battery it happens a lot
During flight fewer flights because ack was fast
Under some circumstances the device could be slow to respond
Shouldnāt fall out of the sky due to unresponsive device
Pattern of IO weāre doing with the battery monitor
Before watchdog it may have recovered?
2 second glitch?
Fixed motor outputs
Speculation was correct
Canāt be absolutely certain as we couldnāt reproduce the lockup reliably
Timeouts donāt help in this case
20ms timeout for the transfers
When the timeout goes off the calling thread becomes runnable
Doesnāt run because the i2c interrupt is always active
Do we port to stable?
Wait for testing reports back from master
Matt still looking at gimbal issue
Similar generic interrupt storm prevention for CAN and SPI probably coming
I2c is more susceptible to bus noise
UTC2320 - https://github.com/ArduPilot/ardupilot/issues/12140
Jaaakyās been quite active!
Xplaneā¦.
No lockstep scheduling on xplane
Xplane defaults to type 10
Maybe trying to make it robust for type 2?
This may break fast sampling
Wrong timestamp for samples
UTC2328 - https://github.com/ArduPilot/ardupilot/pull/12126
Merged
Code isnāt ādeadā
UTC2329 - https://github.com/ArduPilot/ardupilot/pull/12120
Adds something on stackā¦
Two messages?
One means harder to misinterpret logs
Merged!
UTC2332 - https://github.com/ArduPilot/ardupilot/pull/12110
Catch reboot time on receive
New message uptime
Confusing
Tridge would prefer āreceiver rebootedā if we can manage it
Would be nice to move it up for other backends to use
Statustext is valuable when you donāt get binary logfiles
Change to only print when reboot detected
Reboot detection method?
We have to redetect the unit
Msss is probably the best way to do it
Doesnāt quite achieve what itās aiming to do
MdB will raise message rate to make detection reliable
UTC2337 - https://github.com/ArduPilot/ardupilot/pull/12106
Merged
PRIu stuff tridge doesnāt like
String concat stuff makes it harder to read
It is more correct
Add a static assert for unsigned length?
MdB hasnāt seen it before
Tridge commented and merged
UTC2342 - https://github.com/ArduPilot/ardupilot/pull/12098
No functional change
More of a discussion to be had on the logic here
Merged
UTC2344 - https://github.com/ArduPilot/ardupilot/pull/12089
Implementation on what we discussed last week
āAā vs āanā
Chose not to argue for 30m on the devcall
Merged!
UTC2345 - https://github.com/ArduPilot/ardupilot/pull/12069
RSC stuff into a library
Cleaning up motorsheli
Found some small logic issues between setpoint and passthrough
Would maintain RSC within old regime
Going to % rather than PWM
Made descriptions more understandable
Randy like the %
RL would like to do RPM or % control on RSC
With Chrisās governor implementation you do use RPM
Open-loop it doesnāt really matter
ESCs typically use a %
Chris would like to do runup based on RPM sensor
Feedback to pilot in % and RPM would be nice
Rather than PWM
So a pilot calculating required RPM based on air pressure etc has a simpler configuration
Tridge isnāt happy with the parameter conversion
Playing with indexes in parent tables means you can play around with indexes in subgroup much more easily
UTC2347 - https://github.com/ArduPilot/ardupilot/pull/12042
Retract mount when critical altitude reached
Should be altitude-above-terrain
Should be the same as landing gear
UTC2358 - RSC control redux
Leonard couldnāt weigh in due to technical issue
Multi uses normalised values by default
So using a percentage would be inconsistent with multi
Carrying around centi-degrees is a PITA
Trying to use -1 to 1 and 0 to 1
Leonard very much not in favour of percentages
MdB also prefers 0-1
AT: I prefer percentages for user visible parameters
MdB: UI can scale things to percentages though, but from an actual param/control I think 0-1 is a lot better
Better than PWM!
Using percentages may not be a good thing
Randy: Multicopters donāt use percentages. Rover and Plane often do
Consistency across vehicles would be good
Tridge: we also use percent/second in Plane
Slew rates
MdB: I want 0-1 in plane
Percentage in science
46 params use percentages
Slew rates
Stop and use time-to-complete in milliseconds
[10:07 AM] To Weekly devcall: @MdB - how would you do slew rates using 0-1 rather than %?
[10:07 AM] (Channel) Michael_duBreuil: time
[10:07 AM] (Channel) Michael_duBreuil: because slew rates are a problem as stands
[10:07 AM] (Channel) Michael_duBreuil: (partly due to the internal type we picked)
Copter uses Hz for very small time constants
Milliseconds for typical slew rates
We use uint8_t for space reasons
Int slew rates are bad (MdB)
Changed mechanical things on an aircraft to get around things
Minimum slew rate
1 microsecond/loop
So on a quadplane you canāt do less than 300 microseconds/second
Quantization issues
Need to change backend to use float PWMs
Tridge did try this but abandoned it after a day
Mixers in multirotors the convention used is -1 to 1 etc
Leonard thinks the parameter space is worth it
We only store parameters that are changed
16kB is the smallest we have in terms of on-board eeprom
Split between parameters and missions
We should log the amount of parameter space into PM
MdB: how many are we actually talking about as well?
[10:15 AM] (Channel) buzz: is it time we started supporting parameters on SDCard?
[10:13 AM] (Channel) PH: donāt think we have any ratios or percentages in sailboats anyway
Problem: we have a difference in conventions across our vehicles
We should fix this but it is going to be very hard to do
Split Copter out from multi?!
[10:16 AM] (Channel) db: So we have an entirely supported SD infrastructure for logging, but weāre not willing to use it for reading a parameter file?
[10:17 AM] (Channel) MdB: buzz: logging writes, if you donāt write the file then sure no big deal make a new one
[10:17 AM] (Channel) MdB: Canāt load params? Now your vehicle is totally off
[10:17 AM] (Channel) db: yes, Iām aware SD cardās fail, but perhaps thatās a compromise that we could live with if thereās appropriate pre-arm checks etc in place.
RSC are all setpoints
1376 4-byte floats
[10:19 AM] (Channel) RandyMackay: Hereās an issue created re logging eeprom size consumed
Rarely set parameters donāt cost much at all
[10:20 AM] (Channel) MdB: there is an issue already about throwing errors if we canāt log to eeprom because itās full
[10:20 AM] (Channel) MdB: In many ways thatās a more critical issue
UTC0018 - Rover and Copter
UTC0021 - https://github.com/ArduPilot/ardupilot/pull/11936
AP_Filesystem API
MdB will merge after heās finished testing it
ā¦ and heās currently patching other things
UTC0022 - https://github.com/ArduPilot/ardupilot/issues/11398
Receive buffer size change made the gimbal work nicely!
UTC0022 - https://github.com/ArduPilot/ardupilot/pull/11339
Noted that it was looking good but that it hadnāt been merged
Needs to be rebased
UTC0024 - https://github.com/ArduPilot/ardupilot/pull/10020
Add peripheral firmware
Again pinging MdB
[10:27 AM] (Channel) MdB: yeah thatās me again
[10:27 AM] (Channel) MdB: I know
[10:27 AM] (Channel) MdB: Iām hearing
[10:27 AM] (Channel) MdB: and backlogged
Ifdef checks may break like the example code
Merged, but MdB reserves the right to complain about this later when stuff breaks
[10:30 AM] (Channel) MdB: Old man hat for me I guess?
[10:30 AM] (Channel) db: ā¦ future mdb says "I told u soā.
[10:30 AM] To Weekly devcall: We need to get MdB a lawn.
UTC0030 - https://github.com/ArduPilot/ardupilot/pull/9525
We donāt have a driver for this
Tridge is adding a note
If we get a driver in that needs this we can look at merging this
But at the moment this is an important protection for existing drivers where you can definitely expect data at >2Hz
Particularly important on SPI
tridge will add a note
UTC0033 - reverting https://github.com/ArduPilot/ardupilot/pull/12131
UTC0037 - Plane update with tridge
3.9.10 went out yesterday
IOMCU UART handling fix
As previously discussedā¦
āThat sounded oddā was worth chasing up
This would look like an unexpected motor failure
UTC0041 - close
1 Like
