set_dofs_velocity, control_dofs_velocity

[55155]

set_dofs_velocity()

control_dofs_velocity

I have a question to ask. In the following cases, there is a very large difference between set and control. I have some understanding of the difference between set and control. However, I think the system does not require as much torque as what occurs with set_dofs_velocity.

To operate using control_dofs_velocity, do I need to adjust the gain values to produce torque equivalent to that generated by set_dofs_velocity?

Or does the torque value generated by set_dofs_velocity not have much significance?

I always enjoy using this system. Thank you very much.

[jgillick]

To your question of set vs control: my understanding is that the set_dofs_* functions do not use the gains or the PD controller, and just set the actuator to those values. However, control_dofs_*, sends the values through the PD controller with the configured gains. For example, if an actuator doesn't have the maximum torque to lift your robot, and you use set_dofs_position, it will still lift your robot. However, if you use control_dofs_position, the actuator will struggle against the weight and be unable to lift it. For this reason, the set_dofs_* functions are best for initial robot reset (setting the initial position/state), but for the actual running of the simulation, it's best to use control_dofs_*.

So, you're right; to operate using control_dofs_velocity, you should adjust the gain and force_range values until you get the desired output. These values should match, or be similar to, the gains of the motor controller you plan to use in real life.

From your screenshots, it's unclear what is being output. Is the output the measured DOF force/torque, or is that what you're sending to [control/set]_dofs_velocity? I'd recommend always sharing as much of your code as possible so that people have a complete picture to answer your question effectively. Thank you for sharing your videos in your post.

[jgillick]

As far as I know, Genesis does not have a method to input or apply torque. Is there a method related to this?

I believe control_dofs_force will do this.

Also, if set_dofs_velocity is used according to the joint type, does the simulator autonomously input angular velocity or torque for R joints, and actuation force or velocity for P joints?

I think so. Looking at the source code it seems that this method just tells the simulator that the velocity state of the joint is that value. So I assume the simulator then calculates everything else around this. The user guide says that using the set methods can "make changes to the robot state without obeying physics".

I am modeling through Fusion360 and describing it in XML for work. As far as I know, I don't understand why such a large force is needed to operate this system. Could this be a phenomenon caused by the equality tag written to describe the closed kinematic chain?

This is indeed strange. I tried your example and I'm a little stumped myself. I removed the equality tag, as well as all bodies under Revolute 10, and it didn't seem to resolve the issue. The only way I was able to get the motor turning was to do the following:

• Remove ctrlrange from the motor in the XML file
• Set kv to 1000
• Set control_dofs_velocity to 1000

This doesn't seem right, and your code is pretty straightforward. It's possible that there's something in the model that's causing some hidden internal resistance/damping.

[55155]

Thank you. There are a few symptoms that might be suspicious, so I’ll check them out.

[55155]

As I understand it so far, the problem lies in the modeling itself. This issue seems to be caused by collisions between links, resulting in abnormal calculation values.

At first, I confirmed that braket2 lost the hole in the middle during the process of being converted to a collision mesh, and thought this was the cause, so I performed the task with braket2 removed.

However, the same amount of abnormal torque occurred, so after changing in add_entity to vis_mode = "collision" visualize_contact = True, I tried it on my car and obtained the following results.

Even after remaking the modeling file several times, the same issue occurs. I am using Fusion 360.

I have roughly two questions as follows.

Using Fusion 360 and fusion360URDF, I am creating a URDF and going through the process of converting it to XML to represent closed loops. When you modeled with Fusion 360, have you ever encountered collisions like the following?

I understand that in rigid_option, enable_collision removes all collisions within the environment, and enable_self_collision removes collisions between links within the same entity. In my case, enable_self_collision does not seem to work properly. Is it possible that my understanding is incorrect? I will attach a photo.

enable_self_collsion = False

enable_collision = False

[jgillick]

Good experimentation. I'm not sure why disabling enable_collision and enable_self_collsion would not address this. It's possible that these settings are more for reporting collisions via the get_contacts method and less for the actual simulation.

What might be happening, is that the collisions are happening due to the convex-hull collision detection. Generally with 3D simulators, the meshes are converted to purely convex shapes to detect collisions. This makes it easier to detect collision because anything detected the inside the borders of the mesh would be considered a collision. In your case, the axel is inside the motor, and the motor axel hole would be closed up while creating the convex collision object. That said, I believe genesis runs the meshes through CoACD in order to preserve non-convex meshes.

One way to view the collision geoms is to view your model with this command: gs view <path to .xml> -c.

If this is the case, try creating the model with the axel not going into the motor body, and instead, start the axel ~0.5mm away from it.

All of what I said also might be invalid because I believe child bodies aren't supposed to be limited by self-collisions. But it could also have something to do with how the closed loop linkage is defined.

[jgillick]

The models I've worked with also come from Fusion360 and I've not been very impressed with the tools to convert from Fusion360 to URDF or Mujoco XML. In my case, I also wrote a post-export script to fix a variety of things like collisions for my model. Mostly, it uses CoACD to create collision geoms for the bodies that need to be collision aware, all other geoms are marked as non-collidable in the XML with the attributes: contype="0" conaffinity="0" group="2". Collidable geoms are given the attributes: contype="1" conaffinity="1" group="3". You can see my model, here. For example, the leg bodies have both non-collidable geoms, for what is visible, and invisible collidable geoms for the simulator.

I'm not sure if any of this is helpful to your case, though.