Georacer
October 2, 2024, 8:04am
1
Attendees (max) : 8
ArduPilot:master ← ohitstarik:fix_wiggle_staging
opened 04:03PM - 08 Jun 24 UTC
This PR implements the fix proposed in issue #25851
The current code to wigg… le the servos in mission waypoint option "Altitude_wait" currently does not wiggle left elevon, and none of the VTAIL Servos. This is due to the output mixers summing out to zero from the respective roll/pitch/yaw commands.
This fix stages the wiggles one after the other so nothing sums out to zero.
I waited to submit this PR until i got around to testing it at least with SITL.
Here's the test: https://www.youtube.com/watch?v=ryS6fTMAQS0
UTC0704
Merged!
ArduPilot:master ← bugobliterator:pr-iomcu-profiled
opened 05:25AM - 02 Aug 24 UTC
* CPU time cost is minimal, only upto 7us per call is consumed.
* Flash and Dat… a Cost is as follows:
Before:
```
BUILD SUMMARY
Build directory: /home/sidbh/Programming/ardupilot-chibios/build/iomcu-f103-dshot
Target Text (B) Data (B) BSS (B) Total Flash Used (B) Free Flash (B) External Flash Used (B)
-------------------------------------------------------------------------------------------------------------------
bin/iofirmware_lowpolh 52404 1196 19300 53600 7836 Not Applicable
bin/iofirmware_highpolh 52404 1196 19300 53600 7836 Not Applicable
```
After
```
BUILD SUMMARY
Build directory: /home/sidbh/Programming/ardupilot-chibios/build/iomcu-f103-dshot
Target Text (B) Data (B) BSS (B) Total Flash Used (B) Free Flash (B) External Flash Used (B)
-------------------------------------------------------------------------------------------------------------------
bin/iofirmware_lowpolh 52160 1196 19296 53356 8084 Not Applicable
bin/iofirmware_highpolh 52160 1196 19296 53356 8084 Not Applicable
```
UTC0706
Some test issues still need to be addressed.
ArduPilot:master ← Georacer:pr/tecs_improvements
opened 03:45PM - 05 Aug 24 UTC
This PR fixes TECS oscillations that would occur once mode TAKEOFF would reach `… TKOFF_ALT`.
Additionally, it harmonizes the takeoff behaviour between modes AUTO and TAKEOFF.
Finally, it fixes a few bugs.
Many thanks to @Hwurzburg for sharing code for fixing the pitch setpoint.
## Notable behaviour changes
1. Mode TAKEOFF and AUTO now behave identically during a takeoff.
2. `TKOFF_LVL_ALT` now also affects AUTO mode.
3. TAKEOFF mode now respects the level-off angles, as it approaches altitude. There should now be significantly less overshoot.
4. The behaviour of TKOFF_ROTATION_SPD now works as advertized. It was inactive before.
## Notable code changes
1. Mode TAKEOFF now spends all of the climb in FlightStage::TAKEOFF, just like AUTO mode did.
2. `TECS::set_pitch_max_limit()` is now split into `TECS::set_pitch_max()` and `TECS::set_pitch_min()`. Its usage in `quadplane.cpp` has been modified accordingly.
3. TECS pitch limits are now applied at the end of the calculation. Before, vertical acceleration limitations were applied last.
5. TECS: `_post_TO_hgt_offset` will now never pull height demand above the target altitude.
6. `mode_takeoff.cpp` is now prevented from switching behaviours from past `TKOFF_ALT`-2m back to climb behaviour. This would cause behaviour switching if the plane would drop slightly lower than 2m from `TKOFF_ALT`.
7. There are many occasions were TECS is overridden both in pitch and throttle. When that happens, TECS is now effectively inactive and will reset itself.
8. Changed behaviour of `TECS_PITCH_MIN` to match description.
9. `servos.cpp` now doesn't try to enforce all of the takeoff throttle logic combinations. Only `TKOFF_THR_MAX` and `TKOFF_THR_MIN`.
## Tests
The following were tested in autotests:
1. Altitude and pitch no longer oscillation upon reaching the takeoff altitude. ✅
2. TAKEOFF and AUTO takeoffs now behave exactly the same in all combinations of `ARSPD_USE` and `TKOFF_OPTIONS`. ✅
3. The level-off of minimum pitch demand now works in TAKEOFF. ✅
4. When `TKOFF_ROTATE_SPD` is nonzero, pitch demand will be 5deg before the rotation speed and will climb up to the minimum takeoff pitch for groundspeed equal to cruise airspeed. ✅
The following were tested in manual SITL:
1. Altitude and pitch no longer oscillation upon reaching the takeoff altitude. ✅
2. The level-off of minimum pitch demand now works in TAKEOFF. ✅
3. When `TKOFF_ROTATE_SPD` is nonzero, pitch demand will be 5deg before the rotation speed and will climb up to the minimum takeoff pitch for groundspeed equal to cruise airspeed. ✅
## Known issues
1. Ground speed is used in some airspeed comparisons.
5. If AUTO is engaged while in flight and has a NAV_TAKEOFF point, it will force the pitch to positive while it gets processed. This lasts for a few cycles.
6. The SITL plane doesn't regulate pitch well when it's flying at full throttle and fast. Nothing to do with this PR, just an observation.
## Future work
1. I noticed that if you load a mission before you get a GNSS fix, the NAV_TAKEOFF waypoint (i.e. next_WP_loc) will be set at coordinates at the home coordinates and altitude. This can break some takeoff logic in AUTO mode.
2. Render `TKOFF_LVL_ALT` a higher-level parameter, as it is now used also by AUTO mode, not just TAKEOFF.
UTC0707
Merged!
ArduPilot:master ← peterbarker:pr/rcmap-runcam-change
opened 08:22AM - 13 Sep 24 UTC
Extracted from https://github.com/ArduPilot/ardupilot/pull/28089
UTC0713
We wait for Andy to test.
ArduPilot:master ← peterbarker:pr/quadplane-available-fix
opened 08:45AM - 24 Sep 24 UTC
one block was guarded, the second not
UTC0716
Andrew : Looks harmless, not much added either. It’s ok.
ArduPilot:master ← peterbarker:pr/ekf3-set-wind
opened 03:37AM - 02 Oct 24 UTC
This is mostly @priseborough 's work, I've just tidied things up a bit.
- I'… ve ensured the wind estimates replay correctly
- I've ensured the `WIND` mavlink message contains the wind estimate while EKF3 is in charge
- I've checked the XKF2[0].VW* messages to contain the supplied data
- the supplied wind estimates don't last long during a bog-standard Plane takeoff in SITL, the Plane replaces them quickly
UTC0719
Peter : I created this PR from an existing branch.A : What happens if NaN is passed as accuracy? It is part of the definition.
We also need to verify the wind direction convention (wind vector vs wind direction of origin).
The message contents are used directly as an EKF wind state.
Peter : Looks like the state is correctly evolving once dead reckoning goes away and the wind message is no longer given.
Looks good, let’s verify the above.
ArduPilot:master ← peterbarker:pr/correct-plane-takeoff-attitude-check
opened 07:30AM - 21 Sep 24 UTC
4.5 backport is here: https://github.com/ArduPilot/ardupilot/pull/28179
UTC0734
There might be some dirty context related to terrain handling.
ArduPilot:master ← peterbarker:pr/wp-reset
opened 02:40AM - 30 Sep 24 UTC
UTC0737
MAVLink definitions is very detailed and we probably don’t support all of it.A : Happy for this to go in.
ArduPilot:master ← peterbarker:pr/importlib
opened 05:57AM - 01 Oct 24 UTC
We fall back to the previous efforts on failure.
Tested back to 3.6
2.7 wa… s a complete write-off due to pre-existing changes.
UTC0742
A : If importlib is supported in all of Python 3.X, then we can probably do away with pkg_resources.
Need to test in Windows.
Icons are pulled via pkg_resources.
Turns out pkg_resources is used in a bunch of places for different reasons.
ArduPilot:master ← peterbarker:pr/fix-unknown-mav-types
opened 06:24AM - 03 Jul 23 UTC
some of these MAV_TYPEs are not known in older bindings, e.g. MAV_TYPE_BATTERY. … Avoid fatal errors here when we're working with older bindings
```
MAV> Detected vehicle 1:1 on link 0
Exception in thread main_loop:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "/home/pbarker/.local/lib/python2.7/site-packages/MAVProxy-1.8.62-py2.7.egg/EGG-INFO/scripts/mavproxy.py", line 1129, in main_loop
File "/home/pbarker/.local/lib/python2.7/site-packages/MAVProxy-1.8.62-py2.7.egg/EGG-INFO/scripts/mavproxy.py", line 819, in process_master
File "/home/pbarker/.local/lib/python2.7/site-packages/pymavlink-2.4.39-py2.7.egg/pymavlink/dialects/v20/python2/ardupilotmega.py", line 16823, in parse_buffer
m = self.parse_char(s)
File "/home/pbarker/.local/lib/python2.7/site-packages/pymavlink-2.4.39-py2.7.egg/pymavlink/dialects/v20/python2/ardupilotmega.py", line 16762, in parse_char
self.__callbacks(m)
File "/home/pbarker/.local/lib/python2.7/site-packages/pymavlink-2.4.39-py2.7.egg/pymavlink/dialects/v20/python2/ardupilotmega.py", line 16750, in __callbacks
self.callback(msg, *self.callback_args, **self.callback_kwargs)
File "build/bdist.linux-x86_64/egg/MAVProxy/modules/mavproxy_link.py", line 950, in master_callback
self.master_msg_handling(m, master)
File "build/bdist.linux-x86_64/egg/MAVProxy/modules/mavproxy_link.py", line 638, in master_msg_handling
if self.heartbeat_is_from_autopilot(m):
File "build/bdist.linux-x86_64/egg/MAVProxy/modules/mavproxy_link.py", line 603, in heartbeat_is_from_autopilot
mavutil.mavlink.MAV_TYPE_BATTERY,
AttributeError: 'module' object has no attribute 'MAV_TYPE_BATTERY'
```
UTC0752
Merged!
ArduPilot:master ← peterbarker:pr/prune-exc-handling
opened 10:52AM - 01 Oct 24 UTC
we supported the incusion of fences within waypoints for a short period of time … in a branch of ArduPilot. This was removed, but we still have cestiges like this
UTC0755
P : This is probably leftover from the effort to have fences as part of the missin. We no longer need that functionality.A : As long as we test it reasonably, it’s fine.