Georacer
December 18, 2024, 9:53am
1
Attendees (max) : 10
ArduPilot:master ← bugobliterator:pr-fix-memerror-periph
opened 06:43AM - 18 Dec 24 UTC
UTC0700
Sid : Bug that can brick the periph on a Cube Node.Andrew : Will be included in the next stable release
MergeOnCIPass
ArduPilot:master ← robertlong13:pr/engine-fail-mask
opened 02:25AM - 17 Dec 24 UTC
Peter Barker accidentally misdocumented the SIM_ENGINE_FAIL parameter. Rather th… an fix the documentation, I'd much rather change the code to align with it. I need a mask-based version of this for something I'm working on.
Normally, I'm guessing it's frowned upon to just change what a parameter does without renaming it, but given that this is SITL, and the docs suggest that this is what we want that param to do, I'm hoping this is okay.
I've also make SIM_ENGINE_MUL default to 0, so you just have to set SIM_ENGINE_FAIL to fail a motor, which I think is more intuitive. I can drop that part if there are objections.
UTC0704
Bob Long : Converted to cover 32 motors.A : Merged!
ArduPilot:master ← rmackay9:rover-dont-persist-streamrates
opened 02:08AM - 17 Dec 24 UTC
This changes means that if the user or GCS uses the [REQUEST_DATA_STREAM mavlink… message](https://ardupilot.org/dev/docs/mavlink-requesting-data.html#using-request-data-stream) to set the desired stream rates, the SRx_xxx parameter changes will not be saved to eeprom. The parameters are still updated (which is probably not good) but they're not saved so they return to their defaults when the vehicle is rebooted.
This makes Rover consistent with Copter
I can imagine that in the distant past we may have received support requests from user asking, "why isn't my telemetry appearing?" but I think those days are long gone and this is no longer necessary
This has been lightly tested in SITL
UTC0707
A : How about we default the stream rates to 1Hz for Copter?Randy : That doesn’t sound so unreasonable.A : And we can start sending that default stream only when we see a heartbeat on a channel.R : We need to thinkg about the cases of MAVLink onboard peripherals.A : We could even differentiate for GCS-marked heartbeats.Matt : The Telemetry Dashboard can’t ask for streamrates, so the FC needs to be the one to have the stream rates correctly set.R : I do think it’s reasonable to have 1Hz be default when you see a GCS.Peter : We could even disabling setting the parameters from the GCS requests. Just comply to explicit param set.
Merged!
ArduPilot:master ← rmackay9:scripting-follow-target-send
opened 12:19PM - 16 Dec 24 UTC
This adds a follow-target-send.lua applet which can send the [FOLLOW_TARGET](htt… ps://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/common.xml#L5532) mavlink message to other vehicles. This will be used in the cooperative lift and/or copter-ship-landing work.
This has been lightly tested in SITL and below is a screenshot from MP's MAVLink inspector sent from a vehicle flying North at 10m/s in Guided mode
I was hoping to test [Follow mode](https://ardupilot.org/copter/docs/follow-mode.html) with [multiple vehicles in SITL](https://ardupilot.org/dev/docs/using-sitl-for-ardupilot-testing.html#swarming-with-sitl) but it looks like mavlink messages are not passed between them.
BTW the mavlink spec for the [FOLLOW_TARGET](https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/common.xml#L5532) message is not too clear on the frame of each field. I've assumed everything is NED
UTC0719
Discussion on target forwarding and emulating a mesh radio network.
Merged!
ArduPilot:master ← peterbarker:pr/convert-better-errors
opened 01:07AM - 15 Dec 24 UTC
Replaces https://github.com/ArduPilot/ardupilot/pull/28790
This provides a us… eful return value to the GCS that they've passed in invalid lat/lng in their command-long positions. Which they shouldn't be using anyway.
```
Board,plane
CubeOrange,0
Pixhawk1-1M,40
```
UTC0728
P : The behaviour changes when one passes NaN as “don’t change location”. Now it wll be set to INT32_MAX and fail.
But the author notes that INT32_MAX is the invalid marker for COMMAND_INT, not NaN.
A : If that’s specified, then it’s probably best we follow spec.
Hard to find examples where us passing INT32_MAX could be disastrous. But some might exist; we need to look.
ArduPilot:master ← andyp1per:pr-fence-warn-margin
opened 09:43AM - 11 Dec 24 UTC
This PR allows you to get a repeated warning when flying outside FENCE_MARGIN bu… t inside the fence itself. Can be enabled by setting FENCE_OPTIONS=4. Multiple people have requested this because they are required to have a hard fence with failsafe action for regulatory reasons but want to know when they are close so they can avoid the action (typically when flying manually)
UTC0741
Andy : Easy for non-polyfences, but for polyfences it’s a bit harder.A : There are already functions to obtain distances of a fence from a point or line.
That might actually be more useful, allowing to fly close to the fence in parallel.Randy : AC_Avoidance also offers a fence within a fence.A : A fence-margin action doesn’t sound so bad, for a future PR.
ArduPilot:master ← bugobliterator:pr-sched-rate-prearm-check
opened 12:22AM - 19 Nov 24 UTC
This PR adds a prearm check that ensures that we are reading gyro data atleast a… s fast as we are running our main loop, where all controllers run at. We do this for all the INS sensors that are enabled.
This avoids a situation where user might have set SCHED LOOP RATE faster than gyro poll rate or primary gyro with appropriate backend rate but forgot to do so for the rest.
UTC0759
A : Let’s change the minimum multiplier at 1.8 to cover the case of the LSM IMU.
ArduPilot:master ← bugobliterator:pr-icm45686-loop-rate
opened 04:07AM - 17 Jul 24 UTC
TLDR; this PR allows users to be able to better control how fast we read ICM4568… 6, previously we were only limited to 3.2KHz and 6.4KHz. With this PR 0.8, 1.6, 3.2 and 6.4 KHz will be achievable. And for all boards except CubeRedPrimary, the default Sensor read (FIFO read) rate will be 1.6KHz, which was previously 3.2KHz.
Additional Notes:
* We seem to be always setting ICM45686 backend loop rates atleast at 3.2KHz when fast_sampling was requested. And at 1.6KHz when it isn't.
* This PR modifies the rate at which we read from FIFO depending on requested gyro rates. We still sample at 3.2KHz or 6.4 KHz depending on requested backend loop rates, we just read from FIFO based on what read rate is requested.
When fast sampling is not requested we read FIFO at 0.8KHz
Currently there are 6 flight boards that are using ICM45686, CubeOrangePlus, CubeRed, Here4FC, Pixhawk6X and ZeroOneX6. As it stands in master all 6 boards are polling the sensor 3.2KHz.
There is a hard limitation in current master which doesn't even allow users to set the backend rate to value lower than 3.2KHz. Basically even if you had fast sampling turned off the backend rate will be stuck at 3.2KHz.
With this PR following configurations are achievable:
On CubeOrangePlus, Here4FC, Pixhawk 6X and ZeroOneX6, this PR will change the polling rate from 3.2KHz to more reasonable value of 1.6KHz as the default (As all of these boards have FAST_SAMPLING turned on for all IMUs by default). The sample rate on the IMU still remains as 3.2KHz though
If user needs to have faster polling, they can set INS_GYRO_RATE parameters to get polling rate of 3.2 and 6.4.
On CubeRedPrimary, this will put the primary IMU at polling rate of 1.6KHz and other two at 800Hz. This is because default INS_FAST_SAMPLE mask is set to 1.
As a means of safety this PR will ensure that current users setup don't break in case they are using higher SCHED_LOOP_RATE values https://github.com/ArduPilot/ardupilot/pull/28672
The PR also adds support for showing both the Loop Rate and Sample Rate of the IMU for InvensenseV3. This signifies the difference between the two values. We have been displaying these values for Invensensv2 and v1 as well. We did it by the means of two values separated by / like so :
```
snprintf(banner, banner_len, "IMU%u: fast sampling enabled %.1fkHz/%.1fkHz",
gyro_instance, _gyro_backend_rate_hz * _gyro_fifo_downsample_rate * 0.001, _gyro_backend_rate_hz * 0.001);
```
Flight Logs:
CubeOrangePlus LR 0.8 / SR 3.2 : https://droneshare.cubepilot.com/#/s/log?b=1721188076568&c=5a75a9ee-43ef-11ef-a740-b360934a095f&d=CubeOrangePlus+LR+0.8+%2F+SR+3.2&e=2&a=cbfcd2fc-3fa9-11ed-b631-b97a8244eade
CubeOrangePlus LR 1.6 / SR 3.2 : https://droneshare.cubepilot.com/#/s/log?b=1721188057353&c=4f01d6a9-43ef-11ef-a740-7fca103c5c87&d=CubeOrangePlus+LR+1.6+%2F+SR+3.2&e=2&a=cbfcd2fc-3fa9-11ed-b631-b97a8244eade
CubeOrangePlus LR 3.2/ SR 3.2 : https://droneshare.cubepilot.com/#/s/log?b=1721187986195&c=2497d6a7-43ef-11ef-a740-11b81cb1ae46&d=CubeOrangePlus+LR+3.2%2F+SR+3.2&e=2&a=cbfcd2fc-3fa9-11ed-b631-b97a8244eade
UTC0804
Merged!
ArduPilot:master ← peterbarker:pr/dcm-true-airspeed-bug
opened 12:26AM - 25 Nov 24 UTC
This is based on https://github.com/ArduPilot/ardupilot/pull/28727 . ~Until tha… t is merged only the top two commits should be looked at in this PR.~ That PR has been merged.
The drift correction code was using EAS when it should be using TAS.
We were returning TAS instead of EAS when no airspeed present.
Ping @luweiagi who dug up these issues in https://github.com/ArduPilot/ardupilot/issues/25846
UTC0808
Merged!
ArduPilot:master ← peterbarker:pr/short-rtl-failsafe
opened 04:09AM - 26 Oct 24 UTC
This PR adds the ability to enter RTL as a short-failsafe action. From the requ… est:
```
We still want both a short and a long failsafe action. To clarify, this is what we want to do:
When connection is lost continue for X seconds
After X seconds: RTL
If connection still not recovered after Y seconds: Glide
If FS_Short could do RTL, it could take care of #1&2, and FS_Long could take care of #3
```
UTC0810
A : What would happen upon recovery from Short FS (RTL)? RTL loses state.
It feels this should be a Lua script.vehicle**:get_failsafes_active() and decide yourself on the action.
Having a formal way to handle and dictate failsafe behaviour in scripts would be nice; people often need special FS behaviour.
ArduPilot:master ← andyp1per:pr-primary-gyrp
opened 09:36AM - 15 Aug 24 UTC
Split out from https://github.com/ArduPilot/ardupilot/pull/27029
This normali… zes the usage of the "primary" gyro in the IMU drivers and gives an opportunity to take action when it changes. We were doing this before with random calls into the AHRS, but really the IMU needs to know this information. This makes it possible to take specific required action in future PRs.
I've turned this into a demo of what this can be used for, most notably to slow down FIFO read rates on non-primary gyros.
On a CubeOrange+ with ```INS_GYRO_RATE=2``` (4KHz):
Before:
```
idle PRI= 1 sp=0x30021CF8 STACK= 296/ 504 LOAD=22.0%
SPI4 PRI=181 sp=0x3002AF58 STACK= 896/1464 LOAD=23.2%
SPI1 PRI=181 sp=0x3002B668 STACK= 824/1464 LOAD=25.2%
```
After:
```
idle PRI= 1 sp=0x30021D00 STACK= 296/ 504 LOAD=34.7%
SPI4 PRI=181 sp=0x3002AF58 STACK= 816/1464 LOAD=22.0%
SPI1 PRI=181 sp=0x3002B668 STACK= 816/1464 LOAD=14.1%
```
The saving is not as great as you might expect, probably down to SPI overhead which can't be avoided but still substantial.
On my fast rate copter with 2x ICM42688 running at 16Mhz or so I get:
Before:
```
idle PRI= 1 sp=0x3001F668 STACK= 296/ 504 LOAD= 4.7%
SPI1 PRI=181 sp=0x20003538 STACK= 848/1464 LOAD=17.7%
SPI4 PRI=181 sp=0x20003B50 STACK= 848/1464 LOAD=16.3%
```
After:
```
idle PRI= 1 sp=0x3001F670 STACK= 296/ 504 LOAD=12.8%
SPI1 PRI=181 sp=0x30021838 STACK= 816/1464 LOAD=19.1%
SPI4 PRI=181 sp=0x20002720 STACK= 824/1464 LOAD= 8.3%*
```
Which is the difference between on the edge and comfortable
With @bugobliterator 's SPI PR https://github.com/ArduPilot/ardupilot/pull/28093 I get further benefit:
```
idle PRI= 1 sp=0x3001F670 STACK= 296/ 504 LOAD=15.4%
SPI1 PRI=181 sp=0x30022188 STACK= 816/1464 LOAD=15.9%
SPI4 PRI=181 sp=0x30021B70 STACK= 824/1464 LOAD= 7.6%*
```
UTC0826
A : Why is the new header necessary for Invensense v1/2 and not for other IMU drivers?Andy : Peraps because there were changes for fast rates that made the difference.A : No need to treat primary gyro and accel separate. They are always on the same IMU.
ArduPilot:master ← agising:AP_Scripting_GLIDE_INTO_WIND
opened 07:28AM - 28 Jun 24 UTC
As a response to issue #6145.
A LUA script example enables the requested featur… e and shows yet an other example of how to build LUA-scripts.
Script will do the following:
- If set up according to instructions, plane will turn into wind via RC-override as soon as FS_LONG has triggered GLIDE (FBWA).
UTC0833