rroche
March 18, 2020, 5:13pm
1
Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Meeting ID : 946 175 205Join using your mobile/desktop
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...
Call in using your phone, find your local number : Zoom International Dial-in Numbers - Zoom
Mar 24, 2020
Call Moderators
@MichaelSchaeuble
@rroche
Agenda
Pixhawk Standard FMUv[5X, 6, 6X]
Pixhawk Smart Battery
Pixhawk Payload
Mailing List
Dail In
Join Zoom Meeting
One tap mobile
+14086380968,567710856# US (San Jose)
+16468769923,567710856# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 876 9923 US (New York)
+1 669 900 6833 US (San Jose)
Meeting ID: 567 710 856
Find your local number: https://zoom.us/u/aetSYKbiMF
Errata and Feedback
Let me kn…
PX4 Autopilot Flight Testing, by the Dronecode Test Team. Sponsored by Dronecode.
[Link to log archive] )
2 PR’s assigned
0 issue reported this week.
[image]
#14304
FW position controller: move from global to local position #14298
PX4:master ← PX4:spi_i2c_config_refactoring_drivers_2
opened 01:37PM - 20 Mar 20 UTC
This is the last one in the series of https://github.com/PX4/Firmware/pull/14386… : it updates the remaining drivers and removes the old board configurations.
Other changes:
- simplified the chip-select code, by avoiding deselecting all others. This reduces CPU load by almost 1% on a Pixhawk cube (bringing us back to where it was before). @davids5 can you have a look? It's in https://github.com/PX4/Firmware/commit/233479db71a14b3aa85c271e974ab6eed42cefde.
- disable SPI locking, if the configuration allows it (i.e. if no NuttX drivers run on the same bus). Reduces CPU load on a Pixhawk cube by **4%**, on pixhawk 4 and v5x by **2%**.
### Testing
Tested on:
- pixhawk 4
- v5x
- pixracer
- pixhawk cube
- nxp/fmuk66-v3
This is [WIP], because there are 3 more drivers remaining that would create conflicts:
- fxas21002c, fxos8701cq (https://github.com/PX4/Firmware/pull/14168)
- ~~QMC5883 (https://github.com/PX4/Firmware/pull/14384). @dagar, I can do it on top of that PR, but I don't have HW to test.~~ https://github.com/PX4/Firmware/pull/14438#issuecomment-601800588
SPI DMA H7 PX4 NuttX support
S32K PX4 NuttX support
@dagar wants to switch all the Invensense drivers over to the new driver structure and filtering architecture. It applies to every Invensese powered board (all except NXP) and needs heavy testing such that we can be confident for the release.
PX4:master ← PX4:pr-new_invensense_drivers
opened 05:44AM - 25 Mar 20 UTC
A lot of this has already received testing in one form or another. This PR final… ly makes the switch to the new InvenSense drivers (almost) everywhere.
- 8 kHz gyro, 4 kHz accel using FIFOs and SPI DMA (mpu6000 accel is 1 kHz)
- significantly reduces jitter in the system (regular driver scheduling synchronized with sensor, no more timer correction fudge factor)
- clip counters
- sensor side DLPF completely disabled (other than mpu6000)
- with IMU_GYRO_RATEMAX drivers can run both faster (up to 4 kHz on new boards) or slower (down to 250 Hz) while still fetching and processing all raw data (8 kHz)
- this let's you configure the system for high performance racing setups or optionally significantly lowering cpu usage when a high rate inner loop isn't necessary
- it's much easier to see at a glance if the sensor and driver are working correctly together
- sensor setup and driver are internally consistent (configured ODR, data ready interrupt, etc), so if something isn't configured or operating correctly it becomes extremely obvious
- drivers have simple data consistentcy check (duplicated accel data) that can be used to set the max SPI speed safely (eg mpu6000, mpu6500, mpu9250 capable of 20 MHz SPI, but have been limited to 10 MHz to reduce transfer errors)
- mpu9250 mag disabled by default (it weirdly impacts the data output rate)
- Note: in many cases the secondary IMUs are still unchanged
- fmu-v2/v3 (lsm303d + l3gd20)
- fmu-v5 bmi055
- fmu-v5x bmi088
- modalal_fc-v1 bmi088
- holybro_durandal-v1 bmi088
TODO: board rotations + testing
- [x] airmind/mindpx-v2
- [x] emlid/navio2
- [x] holybro/durandal-v1
- [x] modalai/fc-v1
- [x] mro/ctrl-zero-f7
- [x] px4/fmu-v2
- [x] px4/fmu-v3
- [x] px4/fmu-v4
- [x] px4/fmu-v4pro
- [x] px4/fmu-v5
- https://review.px4.io/plot_app?log=6a74189a-82d2-4241-91ac-03a5b0dc2ca8
- https://review.px4.io/plot_app?log=f3f445fb-bbf4-433e-bf44-2c5314dce720
- https://review.px4.io/plot_app?log=39718629-fc97-4b0b-a62b-707e0a8dc0df
- [x] px4/fmu-v5x
- [x] uvify/core
@dagar Is testing arming state machine transition issue where it was in SHUTDOWN state and he could not calibrate anymore. The error is quite confusing. It’s a common problem.
No complaints about EKF heading estimator.
No complaints about the hover thrust estimator being enabled by default.
@Roman
PX4:master ← PX4:pr-controlled_backtransition
opened 09:04AM - 17 Mar 20 UTC
This PR enables following features for standard VTOL and tiltrotors:
- decele… ration control via pitch during transition
- lateral control using fixed wing L1 controller
The above features can greatly improve path tracking during transition and reduce overshooting effects. Below you can see an example of a simple mission with the old state and the new state.
This PR also enables direction control in manual modes for both front and back-transition. This is very useful as you can still try to avoid obstacles during transitions.
This now needs a lot of testing in order to identify corner cases and improvements.
**Master:**
**This pull request:**
@sfuhrer still has the pr open to local position setpoints in the fixed wing position controller. It passed already quite some testing and needs review.
PX4:master ← PX4:pr-fw-pos-control-lpos
opened 09:23PM - 04 Mar 20 UTC
With this PR the fixed-wing position controller is changed to consume local inst… ead of global position updates wherever possible (global position is still required for lat/long estimation feedback and thus for lateral position control). It thus enables the use of the altitude control flight mode for fixed-wing/VTOL systems that don't have a GPS sensor, or the GPS fails (thus eg fixes https://github.com/PX4/Firmware/issues/14243).
**Describe problem solved by this pull request**
Have a working fw altitude controller without global pos updates.
**Describe your solution**
Move subscription of fw pos controller from global to local pos where possible.
**Test data / coverage**
Sitl tested with a VTOL and plane.
**Additional context**
All credits to @dagar for initializing and implementing this!
It would be nice to have terrain aware landing tested in simulation because we don’t know anymore if it works or if it breaks with this pr. @Jaeyoung-Lim
Auto kill upon attitude divergence detection in the first 3 seconds after takeoff.
PX4:master ← PX4:pr-fd-takeoff
opened 01:26PM - 19 Mar 20 UTC
During the first few seconds after takeoff, the failure detector is allowed to t… rigger motor lockdown.
This is done for safety reasons to detect tipping-over or unstable tuning gains.
SITL test: takeoff with unstable gains
https://logs.px4.io/plot_app?log=b43c05ec-0330-414a-b069-41309ce13cf5
FYI @Jaeyoung-Lim
Passing through waypoints in a straight line is now done with more speed. There was a bug.
PX4:master ← PX4:pr-smooth-straight-line
opened 01:37PM - 25 Mar 20 UTC
This fixes the issue that makes the drone slow-down even in straight lines due t… o the Z component being constrained to a really small value.
With master:
https://logs.px4.io/plot_app?log=f7efacca-6262-4a65-b4e2-39c7e4f2f5bb
This PR:
https://logs.px4.io/plot_app?log=1692b126-f195-48c1-8150-2b1b499a900e
Thanks @jkflying for the help.
Integrator wind-up fixed for the acceleration setpoint execution.
PX4:master ← PX4:acceleration-control
opened 06:19PM - 22 Feb 20 UTC
**Describe problem solved by this pull request**
More or less last step to fini… sh splitting up and QAing PX4/Firmware#12072. It's based on #245 and introduces processing acceleration setpoints. This enables acceleration feed-forward which the jerk optimized flight tasks by @bresch immediately make use of. It also heavily reduces dependence between collective thrust and vehicle tilt making the demanded tilt less jerky when the altitude control output is changing.
**Describe your solution**
I make the velocity control output acceleration in m/s² which in theory would make the controller tuning more independent of the vehicle's thrust to weight ratio (~hover thrust) but for the initial introduction I introduce a scaling factor using the hover thrust to make the existing gains compatible. To separate the high-frequency altitude control changes from the collective thrust from the demanded tilt I'm switching control strategy to apply horizontal acceleration setpoints assuming hover/gravitational acceleration in the vertical direction effectively directly mapping it to the vehicle's tilt. The vertical acceleration gets projected onto the planned tilt and then executed by setting the collective thrust accordingly. Only in the limit case of more than the maximum thrust tilt gets coupled by being limited using vertical acceleration demand to ensure prioritizing altitude control over horizontal navigation.
**Test data / coverage**
For the basic limit cases, input combinations, failsafe and zero thrust inputs there are unit tests now. I did a lot of SITL testing and multiple outdoor tests with a 250 size, one test on a big multicopter.
**Additional context**
Refactorings that made this change possible: https://github.com/PX4/Firmware/pull/13247, https://github.com/PX4/Firmware/pull/13248, https://github.com/PX4/Firmware/pull/13262, https://github.com/PX4/Firmware/pull/13347, https://github.com/PX4/Firmware/pull/13701, https://github.com/PX4/Firmware/pull/14017
- [x] I still need to change the jerk limits for manual and auto since the tracking is tighter now.
- I discussed with @Jaeyoung-Lim to expose the acceleration on the offboard interface to allow more dynamic flights and a different kind of input that doesn't rely on vehicle internal velocity estimate.
Independent yaw weight and yaw gain.
PX4:master ← PX4:yaw-weight-hotfix
opened 05:22PM - 04 Jun 19 UTC
instead of infering the yaw weight from the gains which can lead to
unexpected … results depending on the particular vehicle tuning.
mavlink:develop ← Katawann:mission-raw-multiple-features
opened 08:23PM - 23 Mar 20 UTC
I added multiple features for MissionRaw:
start/pause/clear/set_current/mission… _finished/subscribe_progress/cancel upload/download
I still need to manage if a RTL command is sent. This is mostly copy/paste from Mission class.
Tests are still required
@TSC21 :
MicroRTPS bridge template improvements:
Continues working in porting Avoidance to ROS2.
No update
Changed how the model is spawned in the world. Which allows spawning the same model in different worlds that are aligned also with the correct map coordinates.
PX4:master ← PX4:pr-spawn-model
opened 06:10PM - 15 Feb 20 UTC
**Describe problem solved by this pull request**
Previously, the name of the wo… rld in gazebo always needed to match the name of the model. This has created a lot of world files that are identical but required just to spawn the model inside the world.
In gazebo, the world files are designed to be interchangable between models. Therefore, there is no need use the world file as a tool to spawn the models.
**Describe your solution**
This PR creates a logic in the `sitl_run.sh` script so that the model is spawned into gazebo, and not included as part of the world. The logic is as the following.
- If there is no <model>.world existing in the worlds directory, the model is spawned in `empty.world`
- If there is a model specific world in the worlds directory, the world '<model>.world` is spawned
- If a world file path is specified on the environment variable `PX4_SIM_WORLD`, this world is spawned.
This creates a breaking change against the sitl_gazebo repository, since all the models will be spawned twice if this is used with the previous approach.
This PR needs to have https://github.com/PX4/sitl_gazebo/pull/414 or it will end up spawning two vehicles
**Describe possible alternatives**
Rather than using environment variables with paths, we can also add worlds as part of a cmake target. However, this has to be predefined, and for a non-predefined world path, I believe a environment variable solution should work.
**Test data / coverage**
Models are spawned correctly. Try
`make px4_sitl gazebo_solo`
**Additional Context**
@hamishwillee This enables you to spawn worlds separately as we discussed
PX4:master ← PX4:pr-world-gps-origin
opened 07:51PM - 23 Mar 20 UTC
This PR adds the ability to utilze the `spherical_coordinate` tag defined in the… `.world` file so that we can define the world location. This allows easily aligning the gazebo world with the map in ground station as shown in the video below.
This PR is a continuation of #438 , and the `sonoma_raceway.world` has been added to demo how to use the `spherical_coordinate` tag
[](https://youtu.be/caPbIHKRUCs)
To try the demo shown above, use https://github.com/PX4/Firmware/pull/14462 and run
```
make px4_sitl gazebo_rover__sonoma_raceway
```
We had the goal to release by the end of March but it currently looks like we slip by week(s).@dagar wants to have the drivers in a decent and consistent shape for the release which is mostly finished and just needs a lot of testing to settle. Please make sure the necessary issues and bug fixes are in the release blocker project Release 1.11 Blockers · GitHub
@david_s5 CI seems to use Astyle 2.x instead of 3.1 which presumably is the stable default version on Ubuntu 18.04. Along with the release we need to get documentation to reference the setup scripts and not mention different packages and or versions. Also we need to use the setup scripts for the CI containers.
? is asking about gimbal driver, the new gimbal protocol and how to get invloved. @JulianOes summarizes that he’s constantly working on the new gimbal protocol which will replace for the current MOUNT_CONTROL and MOUNT_ORIENTATION MAVLink messages. Timeline for first implementations next few weeks. To get involved from the beginning there will be offline discussions on slack. Pull request for documentation:
mavlink:master ← mavlink:gimbal_v2
opened 01:11AM - 06 Mar 20 UTC
Docs for new gimbal API, as per https://docs.google.com/document/d/16pekKRXLN2Fh… lL9YNFP983cjfBKAsDwN0gOSks8USo4/edit
I have populated it initially with an example sequence and the relevant messages. you can also add your existing images as jpgs.
Todos:
- [ ] ~Add `AUTOPILOT_STATE_FOR_GIMBAL` to diagrams.~
- [x] Better diagrams
- [x] More sequence diagrams
- [x] Create component definition page
Let me know below if I failed to capture anything the right way, and if there are any updates, or you have feedback on the call format.
1 Like
