rroche
November 30, 2022, 6:01pm
#1
December 07, 2022
Join us
Agenda
Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release
Community Announcement
Ryan’s Podcast Episode up in PX4 Channel!
uORB Explained Part 4 is out!
Welcome to the final episode of the uORB Explained Series: Part 4! In the past posts, we discussed the following: Part 1: Why we need uORB and its basic functionality Part 2: What uORB is really about, how uORB topics are instantiated, ORB Metadata...
Est. reading time: 16 minutes
Community Q&A (No deep technical discussions)
Guideline for asking a Question
Specify what you are trying to achieve
Specify what environment / platform you are using
Prepare a Link or Document to help understand if possible
First, ask the question on the Slack or create a Github Issue !
If you take over 5 minutes for the question, please continue in Slack or a Github Issue.
Q.1 : adding namespaces to microdds_clients
PX4:main
← beniaminopozzan:pr_microdds_client_add_namespace
opened 12:16AM - 22 Oct 22 UTC
## Describe problem solved by this pull request
1. The `microdds_client` did … not add the namespace to the participant name. As a result when working with multiple vehicles and ROS2 all microdds_agent had the same name.
2. in `sitl` the `microdds_client` was automatically started on `udp` and port `8888`. With multiple vehicles this caused having all the clients connected to the same agent with the same key identifier, breaking the bridge regardless the presence of the namespace.
## Describe your solution
1. The `participant_xml` is created taking into account the desired namespace.
2. The parameter `XRCE_DDS_KEY` is added and used to specify the session key.
3. In `sitl` the `microdds_client` is automatically started on `udp`. ~~Depending on the `px4_instance` variable the port and the namespace are selected:
`microdds_client start -t udp -p "$((px4_instance+8888))" -n "px4_${px4_instance}"`~~
If `px4_instance` is zero, no multiple clients are expected: `XRCE_DDS_KEY` is untouched and no namespace is defined.
If `px4_instance` is greater than zero, multiple clients are expected: `XRCE_DDS_KEY` is set equal to `px4_instance` and the namespace follow the convention `px4_${px4_instance}`.
4. Regardless the value of `px4_instance`, if the environment variable `PX4_MICRODDS_NS` is set, then it is used as namespace.
## Describe possible alternatives
Have the namespace in the form of a parameter (requires string parameters)
## Test data / coverage
### Single client scenario
This solution has been tested in ingnition simulation. For two vehicles:
**terminal 1**
`make px4_sitl gz_x500`
**terminal 2**
`ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888`
#### Expected Output on terminal 3:
```
$ ros2 node list
/px4_micro_xrce_dds
$ ros2 topic list
/fmu/in/obstacle_distance
/fmu/in/offboard_control_mode
/fmu/in/onboard_computer_status
/fmu/in/sensor_optical_flow
/fmu/in/telemetry_status
/fmu/in/trajectory_setpoint
/fmu/in/vehicle_attitude_setpoint
/fmu/in/vehicle_command
/fmu/in/vehicle_mocap_odometry
/fmu/in/vehicle_rates_setpoint
/fmu/in/vehicle_trajectory_bezier
/fmu/in/vehicle_trajectory_waypoint
/fmu/in/vehicle_visual_odometry
/fmu/out/failsafe_flags
/fmu/out/sensor_combined
/fmu/out/timesync_status
/fmu/out/vehicle_attitude
/fmu/out/vehicle_control_mode
/fmu/out/vehicle_global_position
/fmu/out/vehicle_gps_position
/fmu/out/vehicle_local_position
/fmu/out/vehicle_odometry
/fmu/out/vehicle_status
/parameter_events
/rosout
```
### Multi-client scenario
This solution has been tested in ingnition simulation:
**terminal 1**
```
make px4_sitl
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_POSE="0,0" PX4_GZ_MODEL=x500 ./build/px4_sitl_default/bin/px4 -i 1
```
**terminal 2**
`PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_POSE="0,1" PX4_GZ_MODEL=x500 ./build/px4_sitl_default/bin/px4 -i 2`
**terminal 3**
`ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888`
#### Expected Output on terminal 4:
```
$ ros2 node list
/px4_1/px4_micro_xrce_dds
/px4_2/px4_micro_xrce_dds
$ ros2 topic list
/parameter_events
/px4_1/fmu/in/obstacle_distance
/px4_1/fmu/in/offboard_control_mode
/px4_1/fmu/in/onboard_computer_status
/px4_1/fmu/in/sensor_optical_flow
/px4_1/fmu/in/telemetry_status
/px4_1/fmu/in/trajectory_setpoint
/px4_1/fmu/in/vehicle_attitude_setpoint
/px4_1/fmu/in/vehicle_command
/px4_1/fmu/in/vehicle_mocap_odometry
/px4_1/fmu/in/vehicle_rates_setpoint
/px4_1/fmu/in/vehicle_trajectory_bezier
/px4_1/fmu/in/vehicle_trajectory_waypoint
/px4_1/fmu/in/vehicle_visual_odometry
/px4_1/fmu/out/failsafe_flags
/px4_1/fmu/out/sensor_combined
/px4_1/fmu/out/timesync_status
/px4_1/fmu/out/vehicle_attitude
/px4_1/fmu/out/vehicle_control_mode
/px4_1/fmu/out/vehicle_global_position
/px4_1/fmu/out/vehicle_gps_position
/px4_1/fmu/out/vehicle_local_position
/px4_1/fmu/out/vehicle_odometry
/px4_1/fmu/out/vehicle_status
/px4_2/fmu/in/obstacle_distance
/px4_2/fmu/in/offboard_control_mode
/px4_2/fmu/in/onboard_computer_status
/px4_2/fmu/in/sensor_optical_flow
/px4_2/fmu/in/telemetry_status
/px4_2/fmu/in/trajectory_setpoint
/px4_2/fmu/in/vehicle_attitude_setpoint
/px4_2/fmu/in/vehicle_command
/px4_2/fmu/in/vehicle_mocap_odometry
/px4_2/fmu/in/vehicle_rates_setpoint
/px4_2/fmu/in/vehicle_trajectory_bezier
/px4_2/fmu/in/vehicle_trajectory_waypoint
/px4_2/fmu/in/vehicle_visual_odometry
/px4_2/fmu/out/failsafe_flags
/px4_2/fmu/out/sensor_combined
/px4_2/fmu/out/timesync_status
/px4_2/fmu/out/vehicle_attitude
/px4_2/fmu/out/vehicle_control_mode
/px4_2/fmu/out/vehicle_global_position
/px4_2/fmu/out/vehicle_gps_position
/px4_2/fmu/out/vehicle_local_position
/px4_2/fmu/out/vehicle_odometry
/px4_2/fmu/out/vehicle_status
/rosout
```
## Additional context
I used ignition fortress source compiled for this test. And even if #20319 is fully functional, as the associated PR in gz has been merged, I had to manually modify the gazebo version to overcome #20342.
Q.2: Flash overflowing, how do we fix this? - Jay
For example in this PR: Add fixed wing rate control module by Jaeyoung-Lim · Pull Request #20237 · PX4/PX4-Autopilot · GitHub
Q.3: Pixhawk 6C not receiving RC data
I am testing latest master based on what had a chat about last meeting. The very first issue is I have no RC (13.2 is ok). My Pixhawk 5X is ok with RC. I am using Radiolink RS12 with SBUS by the way.
cc: @dagar
Some outputs are below:
nsh> dmesg
HW arch: PX4_FMU_V6C
HW type: V6C000000
HW version: 0x000
HW revision: 0x000
PX4 git-hash: 45b390b0bfe21fc591b36ec898f6fc0791fc4729
PX4 version: 1.13.0 80 (17629312)
OS: NuttX
OS version: Release 10.2.0 (167903487)
OS git-hash: 6bafcb22b7d62184fd1158c…
Q.4: HITL Fixed wing takeoff not working
opened 06:41AM - 31 Oct 22 UTC
I used the pr-hitl-support branch code, I show the detail:
the command as follo… ws:

then the px4 connect the qgc via udp, I inserted those code to read the accel and gyro in the file of sensor_imu_plugin.cpp in realtime. Like this:

I load a fly plan into px4 and run the mission mode, but it can't runaway takeoff. And the accel and gyro data flow Like this:

I don't konw where the problem is.
Probably because the actuator output mapping isn’t correct between the PX4 and Simulation
Probably not supported now.
There is a hanging PR to support HITL with jMAVSim, but it isn’t done yet.
Auterion:master
← Auterion:pr-hil-support
opened 09:46PM - 22 Oct 20 UTC
**Describe problem solved by this pull request**
Currently the `px4-jsbsim-brid… ge` can only be used to run Software-In-The-Loop(SITL) simulations. While this is useful for evaluating the software changes in firmware, it may not reveal issues that may appear only deployed on hardware. PX4 also supports [Hardware-In-The-Loop(HITL) simulation](https://dev.px4.io/master/en/simulation/hitl.html#hardware-in-the-loop-simulation-hitl). However, this was not exposed to the jsbsim-bridge
**Describe your solution**
This commit adds configuration options for running HITL simulation with the PX4 JSBSim bridge.
The device path / baudrate can be passed with the command line when running the binary directly with flag `-d` and `-b`.
e.g.
```
HEADLESS=1 ./jsbsim_bridge rascal -d /dev/ttyACM0 -s ~/src/Firmware/Tools/jsbsim_bridge/scene/LSZH.xml
```
or to set the baudrate
```
HEADLESS=1 ./jsbsim_bridge rascal -d /dev/ttyACM0 -b 921600 -s ~/src/Firmware/Tools/jsbsim_bridge/scene/LSZH.xml
```
The bridge is configured to be run with a HITL when the device path `-d` is provided. The baudrate is configured to be `921600` by default, but can be also configured through a `-b` flag.
**Test data / coverage**
[WIP]()
**Additional context**
- Fixes https://github.com/Auterion/px4-jsbsim-bridge/issues/27
Project Updates
P.1 : Arbitrary Mag orientation feature - Junwoo
PX4:main
← junwoo091400:pr_mag_arbitruary_rotation
opened 01:22PM - 19 Sep 22 UTC
## Describe problem solved by this pull request
Previously, the rotations for t… he magnetometer was confined to MAVLink defined [MAV_SENSOR_ORIENTATION](https://mavlink.io/en/messages/common.html#MAV_SENSOR_ORIENTATION), which doesn't allow setting non 45-degree multiple sensor orientation.
This was a limiting factor for drones with magnetometer that has Magnetometer installed in Euler angles of something like 37 degrees, 58 degrees, etc.
## Describe your solution
Enables setting arbitrary euler angle for magnetometer orientation, which would allow users to set angles like 37 degrees in yaw, which is useful for Alta X for example
### Added parameters
Parameters that defines the Euler angle for the orientation the Magnetometer is at were added:
- CAL_MAG${i}_ROLL
- CAL_MAG${i}_PITCH
- CAL_MAG${i}_YAW
## Describe possible alternatives
Quaternion?
## Test data / coverage
TODO
## TODO
- [ ] Add QGC UI to dynamically visualize this Euler angle setting for custom rotation
## Discussion
Currently, due to bringing in the MAV_SENSOR_ROTATION_CUSTOM enum, which breakes the sequence of numbers, and bumps up the value to 100, the `ROTATION_MAX` can no longer be used to calculate the number of rotations we support in PX4.
You can read more about enum members number count issue [here](https://stackoverflow.com/questions/14989274/is-it-possible-to-determine-the-number-of-elements-of-a-c-enum-class).
Would there be a good solution for this?
Before sensors: prefix mag config param SENS instead of CAL by bresch · Pull Request #20723 · PX4/PX4-Autopilot · GitHub goes in, shouldn’t we get this in first? @bresch
P.2: State estimation wrong with VICON based real flight - Salvatore
General Discussions
D.1 : HITL Support in PX4
D.2: Learnings from Discord call
With more than 25 ppl, we can’t get the video selfie stream working
Calender needs to be updated to use the Discord server
Sharp image resolution (can u read this )
Weekly Overview
Github
Recently updated Issues / PRs in PX4-Autopilot Link
Pull Requests
*
Issues
*
Slack
Last Dev-Call
PX4 Dev Call: November 30, 2022
Seems like it is empty. Did no-one log the meeting last week?
High priority queue
Discussion based on: High-Priority Queue · GitHub
Release