rroche
November 30, 2022, 6:01pm
#1
Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release
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
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.
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.
For example in this PR: Add fixed wing rate control module by Jaeyoung-Lim · Pull Request #20237 · PX4/PX4-Autopilot · GitHub
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…
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
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
With more than 25 ppl, we can’t get the video selfie stream working
Calender needs to be updated to use the Discord server
Recently updated Issues / PRs in PX4-Autopilot Link
Pull Requests Issues
PX4 Dev Call: November 30, 2022
Seems like it is empty. Did no-one log the meeting last week?
Discussion based on: High-Priority Queue · GitHub
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
Project Updates
General Discussions
Sharp image resolution (can u read this 
)
Weekly Overview
Github
Slack
Last Dev-Call
Release