# Uavcan\_node: distance\_sensor publisher orientation parameter **URL:** \ **Category:** PX4 Autopilot\ **Created:** [August 7, 2026, 9:40am UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331 "2026-08-07T09:40:42Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![samhsieh251](https://discuss.px4.io/letter_avatar_proxy/v4/letter/s/77aa72/32.png) [@samhsieh251](https://discuss.px4.io/u/samhsieh251)\ **Post date:** [August 7, 2026, 9:40am UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/1 "2026-08-07T09:40:42Z")
Hi ! "Recently, we encountered an issue where the distance\_sensor orientation does not match the PX4 configuration.On the UAVCAN node (ToF module) side, I ran the listener distance\_sensor command in the MAVLink console while the ToF instances were in the OPERATE state. Most of the published data is correct (such as timestamp, ID, and distance). However, the orientation information always shows 25 (Down Facing), even when configured to other directions like Right or Left Facing.Upon investigation, I found that the current source code does not seem to handle orientation information at all: PX4-Autopilot\src\drivers\uavcannode\Publishers\RangeSensorMeasurement.hpp. Could you please help check this implementation? Thanks! BR, Sam. ---
**Author:** ![cdtje-ht](https://discuss.px4.io/user_avatar/discuss.px4.io/cdtje-ht/32/22186_2.png) [@cdtje-ht](https://discuss.px4.io/u/cdtje-ht)\ **Post date:** [October 21, 2026, 12:09pm UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/2 "2026-10-21T12:09:57Z")
Hi, I also encountered this issue. Does someone know if there is already some fix proposed for this? I have tested this with an ARK-dist sensor, however, I suppose this will be also the issue for other distance sensors. I want to add more distance sensors, to use collission avoidance, but this will not work if PX4 thinks all sensors are facing downward. PX4 checks if orientation\_defined is true. if not, orientation is set to facing downward, otherwise the set orientation is used. When I inspected the DroneCan messages, I found out that orientation\_defined is always set to false. I also tested some code for this, which seems to work. I added code to set orientation\_defined to true and some orientation. When inspecting the dronecan messages, this worked! Also I flashed my cubeorange with the latest development build (from the main github branch). then I used the mavlink inspector and saw that my distance sensor has a different orientation than 25. Kind regards, cdtje ---
**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\ **Post date:** [October 21, 2026, 3:29pm UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/3 "2026-10-21T15:29:45Z")
Hi Sam and cdtje-ht, I checked the current PX4 source, and there appears to be a concrete issue worth investigating in the DroneCAN range sensor orientation path. In `src/drivers/uavcannode/Publishers/RangeSensorMeasurement.hpp`, the publisher populates the measurement timestamp, sensor ID, range, field of view, sensor type and reading type, but does not explicitly populate `beam_orientation_in_body_frame`. On the receiving side, `src/drivers/uavcan/sensors/rangefinder.cpp` checks `orientation_defined` and falls back to `ROTATION_DOWNWARD_FACING` when that flag is false. This is consistent with the behaviour you observed. I would recommend checking which firmware and publisher implementation the ARK-dist node actually uses before making changes. A robust fix should populate both `orientation_defined` and the correct orientation representation derived from the sensor’s configured mounting direction, rather than hard-coding a single direction. For validation, I would suggest: - Testing downward, forward, left and right orientations. - Checking the raw DroneCAN message. - Verifying the corresponding `distance_sensor` orientation on PX4. - Confirming that multiple sensors retain their individual orientations. - Testing the relevant obstacle-distance or collision-prevention integration separately. The fact that the orientation now appears correctly in MAVLink Inspector is encouraging, but it would be useful to confirm the complete data path. Could you share the exact ARK-dist firmware version and the orientation-related code change you tested? That would help determine whether a minimal upstream PR is appropriate. Best regards, Yiğitcan Öztürk PAMILANGA LIMITED ---
**Author:** ![cdtje-ht](https://discuss.px4.io/user_avatar/discuss.px4.io/cdtje-ht/32/22186_2.png) [@cdtje-ht](https://discuss.px4.io/u/cdtje-ht)\ **Post date:** [October 22, 2026, 8:01am UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/4 "2026-10-22T08:01:37Z")
Hi Yiğitcan, I don’t know actually which firmware ARK is exactly using, since I saw on their discord that they used a closed firmware version. The firmware version on the sensors was v1.18.0.2 (48fb05b9). This is currently the latest firmware. But to fix this issue, I changed `src/drivers/uavcannode/Publishers/RangeSensorMeasurement.hpp`. The code I have added is listed below. I have build the firmware with `make ark_dist` ```cpp auto &orientation = range_sensor.beam_orientation_in_body_frame; orientation.orientation_defined = true; orientation.fixed_axis_roll_pitch_yaw[0] = 0; orientation.fixed_axis_roll_pitch_yaw[1] = 0; orientation.fixed_axis_roll_pitch_yaw[2] = 0; if (dist.orientation <= distance_sensor_s::ROTATION_YAW_315) { // PX4 yaw values 0..7 represent 45-degree steps. // DroneCAN uses 6 units per 90 degrees. int yaw = static_cast(dist.orientation) * 3; // Normalize into the signed DroneCAN int5 range. if (yaw > 12) { yaw -= 24; } orientation.fixed_axis_roll_pitch_yaw[2] = yaw; } else if (dist.orientation == distance_sensor_s::ROTATION_DOWNWARD_FACING) { // Downward: -90 degrees pitch. orientation.fixed_axis_roll_pitch_yaw[1] = -6; } else if (dist.orientation == distance_sensor_s::ROTATION_UPWARD_FACING) { // Upward: +90 degrees pitch. orientation.fixed_axis_roll_pitch_yaw[1] = 6; } else { // Unsupported or custom orientation. orientation.orientation_defined = false; } ``` I have tested downward, upward and all yaw orientations by changing parameter `SENS_AFBR_ROT`(which is the parameter for the rotation) to all possible orientations (0-7, 24 and 25). Also when the parameter is another number (i.e. 9), orientation in the mavlink inspector became 25, which is (what I believe) the intended behaviour. This is also tested with 2 distance sensors, both with a different orientation, and they both hold their different orrientation. A corresponding dronecan message for a sensor with rotation parameter set to 7 (-45 degrees yaw) `timestamp:` ` usec: 0 # UNKNOWN` `sensor_id: 0` `beam_orientation_in_body_frame:` ` fixed_axis_roll_pitch_yaw: [0, 0, -3]` ` orientation_defined: true` `field_of_view: 0.0349` `sensor_type: 2 # LIDAR` `reading_type: 1 # VALID_RANGE` `range: 1.0771` Before this fix the dronecan message shows `always orientation_defined: false` and `fixed_axis_roll_pitch_yaw: [0, 0, 0]`, so this seems to fix the problem. currently I don’t have access to a setup to test the collission prevention, so it would be nice if someone is able to test this. Kind regards, cdtje ---
**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\ **Post date:** [October 22, 2026, 5:03pm UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/5 "2026-10-22T17:03:00Z")
Hi cdtje, Thanks again for the detailed implementation and testing. The results look promising, particularly the successful tests with two independently oriented sensors. There is one detail I would recommend verifying before submitting an upstream PR: the pitch sign convention. In the PX4 DroneCAN receiver, the beam direction is calculated using a negative sine of pitch for its vertical component. This suggests that the upward/downward pitch assignments in the proposed publisher code may need to be reversed. Could you confirm that the receiving PX4 instance reports the correct orientations for both upward- and downward-facing sensors, rather than relying only on the transmitted DroneCAN message? Once that is confirmed, I think this would be a good candidate for a focused upstream PR with regression tests covering all supported orientations. The collision-prevention integration can be tracked as a separate validation step. Best regards, Yiğitcan Öztürk PAMILANGA LIMITED ---
**Author:** ![cdtje-ht](https://discuss.px4.io/user_avatar/discuss.px4.io/cdtje-ht/32/22186_2.png) [@cdtje-ht](https://discuss.px4.io/u/cdtje-ht)\ **Post date:** [October 23, 2026, 7:53am UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/6 "2026-10-23T07:53:44Z")
Hi Yiğitcan, If I look at the mavlink messages in PX4, I get the same orientation as set in the distance sensor. So if I set the rotation to downward facing (25), I also receive a downward facing orientation in mavlink. If I set it to upward facing (24), I also receive 24 in mavlink. So, for all available numbers of orientation (0-7, 24 and 25), I receive the same orientation in mavlink. Does this answer your question? And what will be the follow up steps? Do I have to create the git pull request, or will someone else do that? Kind regards, cdtje ---
**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\ **Post date:** [October 23, 2026, 8:27am UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/7 "2026-10-23T08:27:54Z")
Hi cdtje, Yes, that answers my question. Thank you for checking all supported orientations on the receiving PX4 side. The fact that orientations 0–7, 24 and 25 are preserved through the DroneCAN communication path and appear correctly in MAVLink is strong evidence that your fix addresses the original issue. Regarding the next steps, I would recommend that **you open the pull request** , since you developed the implementation and performed the hardware validation. This will also ensure that your contribution is properly attributed to you. I suggest the following: 1. Fork `PX4/PX4-Autopilot` if you have not already done so, and create a branch containing your change to `RangeSensorMeasurement.hpp`. 2. Open a PR against the appropriate upstream branch, following the repository’s contribution guidelines. 3. Include the original problem, the implementation, your ARK DIST firmware version (`v1.18.0.2`, `48fb05b9`), and the results for orientations 0–7, 24 and 25. 4. Mention that you tested two sensors with different orientations. 5. Clearly state that collision-prevention behavior has not yet been validated. I would also recommend adding automated tests for the orientation conversion if practical. A possible PR title is: **`uavcannode: publish distance sensor beam orientation in DroneCAN`** Once you open the PR, please share the link here. I would be happy to review the changes and help with any follow-up issues raised during upstream review. Thanks again for taking this forward! Best regards, Yiğitcan Öztürk PAMILANGA LIMITED ---
**Author:** ![cdtje-ht](https://discuss.px4.io/user_avatar/discuss.px4.io/cdtje-ht/32/22186_2.png) [@cdtje-ht](https://discuss.px4.io/u/cdtje-ht)\ **Post date:** [October 23, 2026, 2:55pm UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/8 "2026-10-23T14:55:17Z")
Hi Yiğitcan, Thank you for your help. I have created the pull request. Please see [https://github.com/PX4/PX4-Autopilot/pull/29406](https://github.com/PX4/PX4-Autopilot/pull/29406) Kind regards, cdtje ---
**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\ **Post date:** [October 25, 2026, 7:46am UTC](https://discuss.px4.io/t/uavcan-node-distance-sensor-publisher-orientation-parameter/49331/9 "2026-10-25T07:46:31Z")
Hi cdtje, Congratulations on getting PR #29406 merged into PX4! It’s great to see the issue progress from the original DroneCAN orientation problem through hardware validation to an upstream fix. Thank you for implementing the solution and contributing it back to the PX4 community. The remaining collision-prevention integration testing can be handled separately if needed. Best regards, Yiğitcan Öztürk PAMILANGA LIMITED