Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.
Community Announcement
Community Q&A
General Discussions
v1.14 has been branched off, and beta is coming next
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 Discord or create a Github Issue !
If you take over 5 minutes for the question, please continue in Discord or a Github Issue.
Where is the thrust factor of the mixer module assigned to?
Answer:THR_MDR_FAC or sth like that, easier to find it via parameter name
Found by henry here:
* The model is: rel_thrust = factor * rel_signal^2 + (1-factor) * rel_signal,
* where rel_thrust is the normalized thrust between 0 and 1, and
* rel_signal is the relative motor control signal between 0 and 1.
*
* @min 0.0
* @max 1.0
* @decimal 1
* @increment 0.1
* @group PWM Outputs
*/
PARAM_DEFINE_FLOAT(THR_MDL_FAC, 0.0f);
Discussion:
It would be cool to real thrust curve accounted for each different motor, instead of a single thrust factor used for now.
Battery scaling exists in the multirotor rate controller for now, but should be moved ideally (but it works! for now)
PX4:main ← henrykotze:pr-can-esc-reverse-range
opened 03:34PM - 30 May 23 UTC
# Context
In certain vehicles, it is advantageous to have propellers that can r… otate in both directions. This is possible with symmetrical propellers or other propeller designs that can generate thrust regardless of the rotating direction.
BeliHeli ESCs and VESC ESCs have the capability to rotate motors in both directions, provided they are correctly tuned and set up. Previously, we used BeliHeli ESCs, where we set the throttle range from 0% at 1500PWM to maximum forward at 2000PWM and maximum reverse at 1000PWM. However, we have now transitioned to using DroneCAN with VESC ESCs.
DroneCAN's ESC commands ([uavcan::equipment::esc::RawCommand](https://github.com/dronecan/DSDL/blob/984553a3559e39fc4853d447b98f3cf0dd41a2f1/uavcan/equipment/esc/1030.RawCommand.uavcan#L2)) are mapped from -8191 to 8191, representing the maximum throttle in the negative and positive directions, respectively. However, the PX4 mixer module only supports positive integers for its outputs ([link](https://github.com/PX4/PX4-Autopilot/blob/70178b66d8f4bc18e74941821217b1ac8e5850b6/src/lib/mixer_module/mixer_module.hpp#L245)).
As a result, we are unable to command the ESC to control the motor in both directions. Although it is possible to override the parameters and use negative integers, the negative value is interpreted as an unsigned integer.
# Implementation
To address this issue, I have modified the `mixer_module` by changing the minimum, maximum, and failsafe types to `int16_t`, allowing the module to output values in the negative range. However, this change affects all output drivers that use unsigned types. Initially, I explored ways to limit the negative range only in the uavcan driver, but I found this approach less desirable, as some outputs would reside outside of the mixer_module. It is preferable to keep all of this functionality within the class.
Since the output parameters (MIN, MAX, FAIL) determine the mixing output, changing them to `int16_t` seemed appropriate to me.
# Test
I have tested this implementation on a DroneCAN VESC ESC by providing commands in both directions, and it resulted in the desired behavior. However, I have not tested the drivers that use unsigned types, such as pwm_output.
I have created this work-in-progress (WIP) PR to gather feedback on the implementation.
Currently mixer module only supports unsigned output values
For bidirectional ESCs, the output must range from negative to positive (not just positive!)
So this PR implements that & enables bidirectional DroneCAN ESC use case.
At the end, desirable to have mixer module output desired unit (e.g. float / rpm / etc), separated for each driver.
Discussions:
Using ‘float’ data type would be nice eventually
For SITL Gazebo, where output is the angles in radians, float is better
Currently Modal AI ESC is also working in a hacky way for reverse directions
Also some other users with UAVCAN reversible esc is having problems too
DSHOT reversible esc isn’t suffering problem since the range is in positive value range (exception)
Action Items:
PX4:main ← henrykotze:update-actuators-on-CA-updates
opened 06:15PM - 20 Apr 23 UTC
## Context
Currently there are no manual pass-through or rather a way in which … the functions allocated to the outputs can be dynamically change during flight to listen to the `manual_control_setpoint` topic in case of an emergency(hardware failure). To fix this, we have our own module which publishes to the `actuator_servos` and `actuator_motors` based on the `manual_control_setpoint` message if we are flying in full manual mode. Once we are in a controlled mode, the `control_allocator` module is the only module publishing to those topics.
Having another module (like ours, or any other module running alongside `control_allocator`) publishing to the `actuator_servos` and `actuator_motors` topics will result in undesired behavior because the `control_allocator` module will introduce unwanted null containing setpoints to the motors and or servos even if there are no updates on the `vehicle_thrust_setpoint` and or `vehicle_torque_setpoint` topic.
Currently the metadata is intertwined with control allocator as a dependency
Having ability to disable control allocator in general would be helpful - Beniamino
Now for offboard control,
Using the control allocator interface, we can funnel the output through the ‘functions’ (e.g. offboard actuator 0, servo 0, etc), and the output will be correctly delivered to actuators via mixer module
Message overloading isn’t desirable, but currently being utilized (e.g. offboard trajectory setpoint)
Action Items
More logic in output function
Deconflict the topics (e.g. remove need to publish offboard related topics appropriately, so that the hold mode’s output doesn’t hijack / hinder offboard not functioning)
More documentation for the DDS topic funneling (?)
Related: [WIP] ROS 2: Library with dynamic modes API by bkueng · Pull Request #20707 · PX4/PX4-Autopilot · GitHub
Changing the build system to colcon (PX4)
Note: the need for moving over to colcon was also mentioned in this meeting from ROS community:
My questions relate to the following PR
PX4:main ← henrykotze:pr-can-esc-reverse-range
opened 03:34PM - 30 May 23 UTC
# Context
In certain vehicles, it is advantageous to have propellers that can r… otate in both directions. This is possible with symmetrical propellers or other propeller designs that can generate thrust regardless of the rotating direction.
BeliHeli ESCs and VESC ESCs have the capability to rotate motors in both directions, provided they are correctly tuned and set up. Previously, we used BeliHeli ESCs, where we set the throttle range from 0% at 1500PWM to maximum forward at 2000PWM and maximum reverse at 1000PWM. However, we have now transitioned to using DroneCAN with VESC ESCs.
DroneCAN's ESC commands ([uavcan::equipment::esc::RawCommand](https://github.com/dronecan/DSDL/blob/984553a3559e39fc4853d447b98f3cf0dd41a2f1/uavcan/equipment/esc/1030.RawCommand.uavcan#L2)) are mapped from -8191 to 8191, representing the maximum throttle in the negative and positive directions, respectively. However, the PX4 mixer module only supports positive integers for its outputs ([link](https://github.com/PX4/PX4-Autopilot/blob/70178b66d8f4bc18e74941821217b1ac8e5850b6/src/lib/mixer_module/mixer_module.hpp#L245)).
As a result, we are unable to command the ESC to control the motor in both directions. Although it is possible to override the parameters and use negative integers, the negative value is interpreted as an unsigned integer.
# Implementation
To address this issue, I have modified the `mixer_module` by changing the minimum, maximum, and failsafe types to `int16_t`, allowing the module to output values in the negative range. However, this change affects all output drivers that use unsigned types. Initially, I explored ways to limit the negative range only in the uavcan driver, but I found this approach less desirable, as some outputs would reside outside of the mixer_module. It is preferable to keep all of this functionality within the class.
Since the output parameters (MIN, MAX, FAIL) determine the mixing output, changing them to `int16_t` seemed appropriate to me.
# Test
I have tested this implementation on a DroneCAN VESC ESC by providing commands in both directions, and it resulted in the desired behavior. However, I have not tested the drivers that use unsigned types, such as pwm_output.
I have created this work-in-progress (WIP) PR to gather feedback on the implementation.
PX4:main ← henrykotze:pr-prearm-default-on-cannode
opened 07:49PM - 08 May 23 UTC
Previously, the DroneCAN message `uavcan::equipment::safety::ArmingStatus::statu… s` was set to STATUS_FULLY_ARMED if we were prearmed or armed. This would result in actuators being able to actuate such as ESC's even if the arm switch on the transmitter were on the disarm position, because the FMU entered prearmed.
This change sets `uavcan::equipment::safety::ArmingStatus::status` to STATUS_FULLY_ARMED if actuator_armed::armed is true.
On the cannode side, we hardcode prearm to true on receiving the uavcan::equipment::safety::ArmingStatus message, to allow servos/lights and other devices to be controlled in a disarmed state.
PX4:main ← henrykotze:update-actuators-on-CA-updates
opened 06:15PM - 20 Apr 23 UTC
## Context
Currently there are no manual pass-through or rather a way in which … the functions allocated to the outputs can be dynamically change during flight to listen to the `manual_control_setpoint` topic in case of an emergency(hardware failure). To fix this, we have our own module which publishes to the `actuator_servos` and `actuator_motors` based on the `manual_control_setpoint` message if we are flying in full manual mode. Once we are in a controlled mode, the `control_allocator` module is the only module publishing to those topics.
Having another module (like ours, or any other module running alongside `control_allocator`) publishing to the `actuator_servos` and `actuator_motors` topics will result in undesired behavior because the `control_allocator` module will introduce unwanted null containing setpoints to the motors and or servos even if there are no updates on the `vehicle_thrust_setpoint` and or `vehicle_torque_setpoint` topic.
1 Like
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
General Discussions