# Cannot reach higher velocity than 100rad/s using continuous joint

I am trying to control a drone from scratch so I downloaded URDF file. I ve used ros_control package, especially velocity_controllers/JointGroupVelocityController in order to rotate with the drone's blades. However, I cannot reach higher velocity than 100rad/s according to /joint_states topic. I tried to delete velocity limits, make it bigger, change mechanicalReduction but nothing worked so far.

  <joint name="X3__rotor_0_joint" type="continuous">
<origin rpy="0 0 0" xyz="0.13 -0.22 0.0763"/>
<axis xyz="0 0 1"/>
<limit effort="100" velocity="20000"/>
</joint>
<transmission name="trans_rotor0">
<type>transmission_interface/SimpleTransmission</type>
<joint name="X3__rotor_0_joint">
<hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface>
</joint>

<actuator name="rotor_0_motor">
<hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface>
<mechanicalReduction>1</mechanicalReduction>
</actuator>
</transmission>


This is the output from /joint_states topic. I set the velocity for rotor_1_joint and rotor_3_joint to 110 but the actual velocity is always max100.

  seq: 1202
stamp:
secs: 14
nsecs: 215000000
frame_id: ''
name: [X3__rotor_0_joint, X3__rotor_1_joint, X3__rotor_2_joint, X3__rotor_3_joint]
position: [71.20939803271263, 782.5205649126912, -71.20941506978261, -782.5226199546329]
velocity: [10.000000000000048, 100.00000000000007, -9.999999999999895, 100.00000000000011]
effort: [0.0, 0.0, 0.0, 0.0]
---


controllers.yaml

#Publish all joint states
joint_state_controller:
type: joint_state_controller/JointStateController
publish_rate: 100

rotors_controller:
type: velocity_controllers/JointGroupVelocityController
joints:
- X3__rotor_0_joint
- X3__rotor_1_joint
- X3__rotor_2_joint
- X3__rotor_3_joint


What should I set in order to have much higher velocity?

edit retag close merge delete

Just out of curiousity: are you thinking of actually trying to raise your drone by getting the rotors to spin "fast enough"?

I'm not sure that is done often (at all?). The simulations typically include special plugins which take the aerodynamics into account and apply the required forces and torques to the vehicle which then results in motion.

I don't know right now why there seems to be a limit of 100rad/s though. My first guess would be it's on the Gazebo side. As the JointStates "only" report whatever Gazebo is doing.

( 2020-05-12 04:35:10 -0500 )edit

Well yes, I hoped that it could be done with right velocity and directions. I did not except amazing movement but that it would be capable to get in the air and thereafter I could try to implement controllers/navigation/sensors etc. So do you think that it is unrealistic and bad approach? I just want to get first touch with drones and have a platform to learn/implement different types of motion planning/navigation.

( 2020-05-12 05:15:52 -0500 )edit
1

I'm not saying anything is a bad idea necessarily.

It's just that for what you describe to work, the simulator would need to support simulation of the aerodynamics of rotors at a rather low-level. At least with Gazebo, I'm not sure it does -- hence why projects like ROTORS don't do that afaik.

But I'm not into drones at all, so perhaps it is actually something done very often.

As I wrote, I'm just curious.

Personally, I would start by taking a look at other existing solutions, such as ethz-asl/rotors_simulator and see what they are doing.

( 2020-05-12 05:46:53 -0500 )edit

Sort by » oldest newest most voted

This is a late reply, but I hope this can be useful to others. As suggested by gvdhoorn, the problem is on Gazebo's side when you are using Gazebo's ODE default physics engine. Here is a quick fix that works for me.

In the sdf file describing your Gazebo simulation environment, you need to set the "physics-->ode-->constraints-->contact_max_correcting_vel" parameter to correspond to the maximum angular speed (rad/s) of any joint you wish to simulate. For instance, for a maximum angular speed of 10000.0 rad/s, a simple working example of an sdf file would be

<?xml version="1.0" ?>
<sdf version="1.5">
<world name="default">
<physics name='default_physics' default='0' type='ode'>
<max_step_size>0.001</max_step_size>
<real_time_factor>1</real_time_factor>
<real_time_update_rate>1000</real_time_update_rate>
<ode>
<constraints>
<contact_max_correcting_vel>10000.0</contact_max_correcting_vel>
</constraints>
</ode>
</physics>
<!-- A global light source -->
<include>
<uri>model://sun</uri>
</include>
<!-- A ground plane -->
<include>
<uri>model://ground_plane</uri>
</include>
</world>
</sdf>


This is a weird workaround, because according to the SDFormat specifications , the "contact_max_correcting_vel" parameter corresponds to the maximum correcting velocities allowed when resolving contacts (and has a default value of 100). This has arguably nothing to do with the maximum angular speed of the joints in a model.

Then in Gazebo's documentation, it is pointed out that

contact_max_correcting_vel This is the same parameter as the max_vel under collision->surface->contact. contact_max_correcting_vel sets max_vel globally.

Again, setting contact_max_correcting_vel should have nothing to do with the maximum angular speed of joints in the model, but I suspect that the global value set for max_vel is also used by ODE's physics engine as the default maximum angular speed for new bodies. For more details, check out the "dWorldSetMaxAngularSpeed" function in ODE's manual.

more