What else is missing? In theory, what other factors complicates the simulation such that it cannot realistically match a real arm?*

Yes, I'm interested in this too. I would like an accurate dynamical model of the UR5 and other UR manipulators. But I don't yet know of a package or project that provides this kind of Gazebo "emulator" for a given robot system that includes both its accurate physical dynamics and captures the effects of any software delays (which might be appreciable and more important than subtle dynamic effects.)

To accurately simulate the dynamic response of the robot to command inputs you really need a model of all of its internal software/hardware/firmware controllers and you also need accurate dynamical models of its actuators.

On the subject of actuation, and a modeling approach to make a Gazebo model more realistic, I've been thinking about it but I think it needs to explicitly handle the actuators at least at a simple level.

I feel like there's an important concept put well here by Russ Tedrake:

http://manipulation.csail.mit.edu/robot.html

One thing that might be surprising is that, despite the fact that the joint dynamics of a manipulator are highly coupled and state dependent, the PID gains for each joint are often chosen independently for each joint, and are constant (not gain-scheduled ).

...

nearly all electric robots have fairly substantial gear reductions, often on the order of 100:1

...

The "reflected inertia" of the arm at the motor is cut by the square of the gear ratio; or the "reflected inertia" of the motor at the arm is multiplied by the square of the gear ratio. This has interesting consequences -- as we move to the multi-link case, we will see that the inertia of the arm is a state-dependent function that captures the inertial coupling of the other joints in the manipulator. The motor inertia, on the other hand, is constant. For large gear ratios, this means the dynamics of the joint are less dependent on the nonlinear effects of joint position and velocity, making it relatively easy to tune constant feedback gains that perform well in all configurations

However, in short, if we're trying to use an effort controller, I think this means that we must have a simple model for how the arm's inertia tries to backdrive the motor inertias. Simply removing the active torque on the motor rotor does not set the joint torque to zero as viewed from the standpoint of the arm's inertia. Rather, setting the motor torque to zero will allow the rotor to freewheel, which actually dominates the overall inertia of the system. The actual effort seen by the "motor coils," which are what we would control with an effort joint interface, is very different from 1/N the joint torques from the manipulator dynamic equations.

I don't know if there's a good plugin framework for modeling actuator dynamics. Just having the gearbox (like the <transmission> tag) isn't enough, I think you need to take rotor inertia into account at minimum. And honestly, I don't even know if the transmission tags are even working? (this is something I'm looking into, trying to understand ros_control better, and will update if I find more)

I believe what is needed to mimic an effort joint interface that's realistic for many real robots is a realistic gear ratio, even if lossless, and an actual spinning rotor inertia, which can be virtual/mathematical. When the motor rotor is stopped or spinning slowly, the effort PID controller then sees that it needs to supply 1/N the torque of the actual arm joint. When the motor is spinning fast, the inertia of the motor dominates the dynamic torque behavior, and the PID controller is largely controlling the spinning inertia of the rotor, with the actual manipulator dynamics of the arm as kind of a small adjustment.

It's not clear to me yet how to make this happen in Gazebo, but I have not yet found a project that's trying to do this. I'd be interested.

Most projects actually just use the Hareware_interface/PositionJointController instead since there's no need for a PID.

I think that is a better approach, to be honest. I understand that this question is linked from and maybe related to this discussion on the universal_robot packages, and I know that there they are discussing the use of effort joint controllers to solve problems with hard contact between the position controlled robot and its environment (I've been experimenting with PR #526 already). However, I think because of the reflected inertia effects in the transmission dynamics discussed above, a PID controller running directly on the robot joint is going to have different dynamics than a PID controller running a motor inertia.

I am actually having some trouble with low "stiffness" of the effort joint controllers for the UR5 in Gazebo. I am still working on documenting my issue and seeing if I can tune them differently and trying to diagnose exactly what's going on.

I think the short-term fix for me is to go back to using a position-controlled or velocity-controlled robot. The UR5 joints are very stiff and the machine uses feedback control to make it "as kinematic as possible," so position or velocity control is not an unreasonable approximation. For the URx robots, I suspect that their primary mechanical deflection is due to elastic deformation of the harmonic drive flexspline rather than anything like backdriven "slip" of the magnetic field in the motor at maximum current. (I do not know this, this just my current working guess). I also think the robot will enter safety stops well below the nominal torque limits of the joints, probably limiting non-kinematic deflections even more.

To fix the "exploding robot" problems seen with position controllers, therefore, I'm thinking of adding some realistic joint elasticity to a kinematically-controlled robot. I have already achieved a "safe" environment for a position-controlled robot by mounting environmental obstacles on spring-damper mounts. See some information here:

https://answers.gazebosim.org/question/26533/properly-making-soft-joints-to-world-in-gazebo-9-ros-melodic/

I think realistic elastic joint deflections comparable to the real robot's stiffness MIGHT keep the robot from exploding on contact with rigid, fixed obstacles, and would also add a bit of inertial and contact/load deflection that is relatively realistic. I don't know yet if this is feasible or not. In my application I'm most concerned with controlling kinematic positioning to the nominal repeatability numbers of the UR5 without having it explode when it touches objects.

Some other kind of more complex load-dependent "deflection" scheme might be possible with plugins, etc. but I don't know enough about that yet to comment intelligently.

My robot cannot accept torque control commands, so there's no inherent benefit in an effort controller for me. For me, the effort controller is to avoid "explosion" on contact, which I've already solved with environmental compliance. I also want to read the joint efforts, which only the effort controller reports on /joint_states. But I believe that this can be solved with other methods, like force-torque sensors in the robot model.

I'm curious, in your application do you have realtime control over the joint torque commands? Or do you also need to use position or velocity commands?

Are you seeing or measuring deviations from desired trajectories in an experimental system that are excessive, or do you want an "emulator" of real hardware to see what would happen before you try hardware on some aggressive/difficult/precise trajectories?

I think it would be very nice to have a "digital twin" of popular robot models that behave as accurately as possible, but this is a large system identification and controller software effort and I think generally the results are not made available as ROS tools for others to use, if they were even developed in a ROS context in the first place. A big part of this is detailed models of the temporal effects of the electronics and software, as well, not just the mechanical dynamics. For example, see

https://backend.orbit.dtu.dk/ws/portalfiles/portal/117833332/Universal_Robot_report.pdf

where there is a very long delay between command and action in the robot electronics itself:

Also, each joint on the physical robot has a PID controller. For a URx robot, you can change those settings. Traveling from position to position or velocity to velocity uses an underlying control law of that controller.

Issues like that on my hardware, which doesn't support external motion control that well, are going to be more significant than physical dynamics and deflections, especially if you try to close an external feedback loop around the robot. Maybe your robot comes with a better real-time control interface designed to be useful in a feedback loop and will not have such issues (and indeed, I think newer URs are better, maybe the ROS driver is fixed, I don't know yet).

I'd be interested in general discussion about this topic. I would like to have an "emulator" of different robots to see what can be done to understand, communicate, and control residual unwanted behaviors all in simulation. But I think an emulator for one robot is a long, involved project in itself.

Comments

I'm curious if you've looked at the gazebo_ros_motors project. I haven't played with it myself yet, but it looks like it takes a more realistic approach to motor modelling in Gazebo

Asked by shonigmann on 2021-06-10 13:10:25 UTC

I haven't looked at that, looks interesting. Thanks!

Asked by danzimmerman on 2021-10-15 12:40:48 UTC

I think, as Dan mentions, arguably the most important detail in relation to simulating real hardware and their corresponding control laws is temporal effects. Sure I can implement a PID controller in Gazebo using many different methods, but it seems that regardless of the dynamic properties that are used, and the route in which PID is implemented, on a model one can't simulate these temporal effects in any real way. If I can design a PID controller that will have 0 s.s. error in Gazebo it is certainly wonderful, but what of rise time? mechanical time constants? These details are arguably just as important, especially because commands will often change before steady state has been reached at all, meaning within a short command sequence a real system and a simulated system in Gazebo will already be behaving fairly differently.

On a similar front, roboticists often come from one of two backgrounds: computer science or control engineering. For those based in controls, like myself, being able to assess my simulated system "open loop" or "closed loop" is very important, but it seems that in Gazebo, neither one can really be simulated. Setting a new velocity, through PID or not, changes this speed instantly. And what if I want my system to have a similar impulse response to the real system? As far as I am aware this really cannot be done as the resulting time history of this actuation will bang on and bang right back off. Any incites on this front would be particularly helpful. Sorry I could not be more help, but I wanted to add my two cents in hopes that some broader attention can be brought to this question.

Comments