Korean Regional Dev Call: December 9, 2020

Jaeyoung-Lim · December 8, 2020, 3:41pm

Agenda

PX4 Dev Call Update
QGC / Dev Guide / User guide 한글화
커뮤니티 QnA
In-Depth Discussion

Join Meeting

일시: 2020년 12월 9일 4 pm (KST)
Meeting Link: https://meet.jit.si/PX4KoreanSIGDevCall

여섯번째 한국어 지역 Devcall을 진행합니다!

혹시 의논하고 싶은 내용이 있다면 아래에 답글형태로 남겨주시면 감사하겠습니다

Agenda
지난주 PX4 Dev Call Update

github.com/PX4/PX4-Autopilot

[WIP] Events interface

PX4:main ← PX4:events_interface_prototyping_comp_info

opened 03:33PM - 27 Nov 20 UTC

bkueng

+3270 -66

This brings the events interface - I've been sidetracked for quite a while but f…inally found some time to continue. For those not familiar: this will replace the `STATUSTEXT` mavlink messages. Full details: https://docs.google.com/document/d/18qdDgfML97lItom09MJhngYnFzAm1zFdmlCKG7TaBpg/edit **How do you use it?** From anywhere in the code, you can do something like: ``` /* EVENT * @description * This is the description. It can be as long as you want, contain arguments, URL's or params. * - value of a: {1} * - value of b: {2} * - value of f: {3:.3} * * Link: <a href="https://docs.px4.io/master/en/config/firmware.html">documentation</a> * * <profile name="dev"> * This is only meant to be shown to developers. * It might contain a parameter, like <param>COM_ARM_MAG_STR</param>, to disable a check. * </profile> * @arg1: a * @arg2: b * @arg3: f */ events::send<uint8_t, uint32_t, float>(events::ID("test"), "Short message describing the event", events::Log::Warning, a, b, f); ``` From that only an event ID + arguments + log level get sent and logged at runtime. Metadata is extracted during build and gets to the GCS through the COMPONENT_INFORMATION API. Some PX4 specifics: - There's a new submodule: https://github.com/bkueng/libevents (for common events, validation and code generation) - the code generation allows to use events from the common namespace (e.g. for calibration protocol) - Required memory usage (for event buffers): 1.7KB - Event extraction from source takes about 300ms - To test I changed the accel calibration to use the events interface, see 34986c1a60c52b23d8a3116673fd27b504a1ecb2. I tested with an artifical event drop rate of 50%, and over telemetry, and it still worked. ### Health and Arming checks Health and arming check results are reported over the events API. There are 2 summary messages that contain overall information about subsystem warnings and errors, and overall arming results per flight mode category + current flight mode. Flight mode categories include Mission, Autonomous, Position, which for example allows a GCS to know whether flying a mission is possible or not, independent from the current mode. Each failure/warning contains the affected subsystem (e.g. IMU) and mode category (allowing a GCS to only show problems for the current mode for example). This and together with continously running the checks and only report on change, requires some changes to the existing code. The structure is similar, so not too big of a change. For an example I added the power + ekf2 checks: ab445394be99ee15efbcf879a6011af07ec395d7. Some requirements: - For predictable results there cannot be additonal checks outside of the arming checks (similar for arming-source-dependent checks) - We cannot feed mode-dependent results into the checks - To cleanly solve cases like `arm -> takeoff -> failsafe triggering`, bigger changes are required. I could imagine a structure like this (w/o having gone through the details): ![commander](https://user-images.githubusercontent.com/281593/100462020-e4cafc80-30c9-11eb-983f-866c6a37515c.png) This PR is on top of https://github.com/PX4/PX4-Autopilot/pull/16039. **Main missing things:** - COMPONENT_INFORMATION + translation workflow + push metadata to server - arming checks and sensor calibration **Open questions:** - how to transition? What version compatibility do we want? I'm sure I left out some things, so feel free to ask, provide any suggestions, ...

github.com/PX4/PX4-Autopilot

Enable acceleration setpoint based takeoff

PX4:master ← PX4:pr-acceleration-setpoints

opened 09:02PM - 08 Sep 20 UTC

Jaeyoung-Lim

+9 -2

**Describe problem solved by this pull request** When sending acceleration setp…oints as part of offboard position setpoints as part of [SET_POSITION_TARGET_LOCAL_NED](https://mavlink.io/en/messages/common.html#SET_POSITION_TARGET_LOCAL_NED) mavlink message, the vehicle would not take off. The reason seems to be that a downward acceleration was being copied while the vehicle was in `flying_but_ground_contact=true` state. **Describe your solution** This PR adds the following. - Enables a acceleration triggered takeoff based on the acceleration setpoint - Fixes the takeoff logic so that the vehicle is able to take off while acceleration setpoints are being sent **Test data / coverage** Having acceleration setpoints do seem to improve the performance of trajectory tracking. The below examples show a log of the vehicle tracking a circular trajectory with and without acceleration feed forward inputs. - (BeforePR) Without Acceleration feedforward setpoints: https://review.px4.io/plot_app?log=3f8f3643-991b-435e-8286-289aa2920803 ![image](https://user-images.githubusercontent.com/5248102/92527345-249aea00-f227-11ea-9b63-0b526ac297d2.png) - (AfterPR) With Acceleration feedforward setpoints: https://review.px4.io/plot_app?log=7515c5b1-bfc1-4026-9a11-8eabda5134c0 ![image](https://user-images.githubusercontent.com/5248102/92527377-311f4280-f227-11ea-8983-cf28ee816341.png) **Additional context** - Acceleration feedforward control was added in https://github.com/PX4/Firmware/pull/14212, but was not functional for offboard control.

github.com/PX4/PX4-Autopilot

Separate out FlightTasks from position control module

PX4:master ← PX4:separate-flight-tasks

opened 12:52PM - 14 Apr 20 UTC

MaEtUgR

+946 -538

**Describe problem solved by this pull request** The FlightTasks library was de…signed to separate the core multicopter position control from the position, velocity, acceleration setpoint generation to fulfill various tasks. The separation hepled a lot in terms of modularity and debuggabilty and the main data flow is through generated message structs like `vehicle_local_position_setpoint` (, `vehicle constraints`, `landing_gear`) but the two pieces are not completely separate. The FlightTasks library is technically still inside the position control module. Also there are certain dependencies e.g. for landing takeoff limiting and similar cases that still lead to unexpected problems every now and then. **Describe your solution** I strated seprating out the FlightTasks library to live in a separate module that I called `flight_mode_manager` with the plan of the Navigator Architecture planning in mind that we aim towards having flight mode classes like flight tasks for all setpoint generation in the future. It's unfinished and I'm trying to separate certain dependencies in a good way to be able to cut a clear line between the modules. The main pain points so far are: - [x] **Position state preprocessing** - The position control module should use the state as published by the estimator and not generate its own mixed state that is not available to other modules or in the log. **EDIT:** This has to be solved in a idfferent pr but I made sure it's no blocker anymore here. - [x] **Emergency failsafe** - I think the position control module should be able to handle the situation where setpoints are gone for a certain time or forever and the setpoint generation would stop publishing when things go really wrong. - [x] **Hard limits vs specified constraints** - We should get rid of specified constraints that get applied in the controller, we already started to do that. The hard limits stay to have sane execution. **EDIT:** This has to be solved in a idfferent pr but I made sure it's no blocker anymore here. - [x] **Land/Takeoff special cases** - Out of limits, more restrictions, safety critical land detection. - [x] **WeatherVane mess** - It's a global object that gets instanciated dynamically and passed around by pointer. It works around the entire architecture and we should move to the local scope where it's actually used. **EDIT:** This has to be solved in a idfferent pr but I made sure it's no blocker anymore here. **Test data / coverage** SITL flies no. Testing for correct takeoff ramp and so on still pending. **Additional context** Discussed starting point from https://docs.google.com/document/d/1N59JHFqL_E9X4b-U0CzxW_eydqXUHZMxAH_FTD30ilk/ Bigger picture tracked in https://github.com/PX4/Firmware/projects/34

github.com/PX4/PX4-Autopilot

Handle takeoff waypoints for rover

PX4:master ← PX4:pr-handle-takeoff

opened 03:45PM - 28 Nov 20 UTC

Jaeyoung-Lim

+7 -0

**Describe problem solved by this pull request** Previously, rover vehicles wer…e not able to handle Takeoff waypoints. The behavior when a takeoff waypoint was passed to a rover vehicle was: - The vehicle would not move since the waypoint was too close - The takeoff waypoint would not get accepted since rovers are not able to climb and reach the altitude I think it might be obvious that one "should not" pass takeoff waypoints to a vehicle. However, QGroundControl only lets you plan a mission that starts with a takeoff waypoint. While this should also be an improvement on the QGC side, I think it is still useful to handle this case on the vehicle side so that the vehicle can still progress with the mission even with a takeoff waypoint **Describe your solution** This adds a special case when handling takeoff waypoints for rover vehicles. The acceptance radius is set to only consider horizontal distance to the waypoint, if the vehicle type is rover. **Test data / coverage** - This was tested in SITL gazebo, with the rover model. ``` make px4_sitl gazebo_rover ``` This log shows a full mission successfully finished starting with a Takeoff waypoint and finished with a RTL: https://review.px4.io/plot_app?log=25fe983b-44d0-4a11-a7c2-2ab9662c35d4

QGC / Dev Guide / User guide 한글화
한글화 프로젝트 관련 메인테이너 필요합니다. 혹시 한글화 프로젝트 메인테이너 롤에 관심있으신 분은 자원해주시면 감사하겠습니다

QGroundControl 한글화 프로젝트
- 진행사항 83%
PX4 User Guide 한글화 프로젝트
- 진행사항 7%

커뮤니티 QnA

In-Depth Discussion

sunabove · December 15, 2020, 2:00am

Hello…
안녕하세요? PX4 한글화에 관심이 있습니다.

Jaeyoung-Lim · December 15, 2020, 11:53am

@sunabove 안녕하세요, 감사합니다 혹시 이번주 한국어 Dev Call에 참여해서 어떻게 참여하실 수 있는지 이야기 나눌 수 있을까요?

sunabove · December 16, 2020, 1:10am

이번주 Dev Call 시간을 알려주시면 감사하겠습니다.

Jaeyoung-Lim · December 16, 2020, 5:10am

@sunabove 매주 같은 시간에 진행합니다

링크는 여기에 있습니다: Korean Regional Dev Call: December 16, 2020

sunabove · December 16, 2020, 6:21am

다음 달부터는 수요일 오후 4시에 참여가 가능합니다. 오늘은 혹 스마트폰에서 참여 가능하면 잠시 참여할 수 있습니다.