Fast-motions with icub's arm

[pattacini]

@khoramshahi commented on Tue Mar 07 2017

Hi,

I would like to generate very fast motion with the new icub's arm (especially the shoulder joint 0 for pitch), and I have two questions regarding this that I would be thankful if you could help me with.

1. how fast can one move this joint (shoulder 0) with regard to safety issues and hardware damage?
2. what is best mode to control for this? Is velocity control with a pre-made velocity profile with a bell-shape a good way to tackle this?

Best,
Mahdi from EPFL

---

@pattacini commented on Tue Mar 07 2017

Hi @khoramshahi

I deem your question of quite general interest for the community, hence let me move it to our Q&A system.

[pattacini]

Hi @khoramshahi

Question 1 does not have a general answer that can suit all conditions, depending very much on the task at hand. Further, we should rather discriminate between peak velocities and average velocities. In this respect, I would say that we shouldn't overcome 200 deg/s peak and 50 deg/s mean velocity. The peak I'm referring to, for example, could be the maximum velocity delivered in a minimum-jerk position profile.

That being said, it is very advisable to start with a design that foresees movements running at most at half of those limits, and then make incremental adjustments to further increase those current bounds.

Question 2 is simpler in that I'd warmly recommend you rely on position-direct control, which allows sending precomputed position references or even planned trajectories obtained online but without being constrained by the feedback readouts. Regarding this, you might want to explore the insights given in the tutorial_joint-interface.

Related issues: #191 #186

[asutcl]

Hi @pattacini,

I am working with @khoramshahi. Thank you for the information. We were able to reach peak velocity. We observed that the velocity of the shoulder would actually plateau around 200 deg/s. Please see the graph below.

We wonder if there are any safety limitations in place. For example, we noticed an output limit on the PID (observed through the yarpmotorgui), could this contribute to the plateau we are seeing? If so is it safe to up this limit?

The reason we ask is two fold. First we have reason to believe the previous iCub we have could go faster. Also, we were under the impression that the iCub arms move faster during the stabilisation movements in the taichi video. It this accurate or is this impression due to the fact that multiple joints are used?

Thank you,
Andrew

[pattacini]

Hi @asutcl

Assuming that the position reference you're sending is a minimum-jerk profile (as it much resembles), you're asking to move the joint with a peak velocity of 337 deg/s and a mean velocity of 180 deg/s. Am I correct? These values do really seem to be too high and scary to me. Fortunately, you did not break the arm.

• In which modality are you commanding the movement? Would you be willing to share the code on Gist? With velocity control and position-direct control there are no particular limitations in the firmware other than the maximum voltage we can deliver to the motor. On the other hand, with position control you should pay attention to the limit in the acceleration that in turn is translated in a maximum allowed velocity; to disable this latter constraint just call the method yarp::dev::IPositionControl::setRefAcceleration() with a very high number. However, again, it's likely that you hit other limitations here.

• To monitor the voltage delivered to the motor and check whether there's a saturation, you can rely on yarp::dev::IPidControl::getOutput(). It will return an adimensional number representing the voltage on the full scale [0, 1333] (usually). I had a quick look to your robot's configuration files and this type of feedback on the first joint should be already available.

[pattacini]

The arms movements performed in the Tai Chi demo are generated in torque mode (essentially by means of a direct control of the voltage delivered to the motors) and are not faster than those achieved via position control. It's more an impression induced by the coordinated choreography of the body movements, as you already noticed.

[asutcl]

Hi @pattacini,

Thanks a lot for your replies. I will try to share the code on Gist either later today or Monday.

Regarding the graph I presented, we very slowly incremented the maximum velocity in order to limit the risks. What we noticed is that up to 200deg/s the actual trajectory would stay close to your planned trajectory. When we carefully pushed it higher, we notice that the only effect it had was on the start and end accelerations and that the joint speed would plateau at roughly 200deg/s for most of the trajectory.

As you pointed out the position reference used for the graph was computed trying to reach a peak velocity of 400deg/s. We did this once we were quite sure that our velocities were not exceeding 200degs/sec as to provide a clear contrast in the graph. We will be more careful with further test.

We are using the position-direct control mode. This will be apparent in the code I will post soon. We will also test with the old iCub we have to see if there is a difference or it was just an impression.

Finally, is there a resource where we can see the maximum velocities of the other joints in the arm? We would like to try to work within the recommended constraints in order to limit risk to a maximum.

Thanks again,
Andrew

[pattacini]

Considering your latest information, I'd say that the limiting factor here is the voltage applied to the motors, which is presumably saturated. You could check that by means of the IPidControl interface, as I pointed out in my previous post.

In this respect, from a quick back-to-back comparison between iCubLausanne01 and iCubLausanne02 it comes out that there are some differences in terms of units and maximum values of the PID settings I'd like to investigate with @randaz81 on Monday.

In theory, you could go faster with the other joints, being the joint 0 and 1 (they're coupled) the most critical. However, my suggestion still holds: don't overcome those values reported above for peak and average velocities.

[pattacini]

Any update on your side?

[asutcl]

Hi @pattacini,

Sorry for not getting back to you sooner. We wanted to see if we could have something up quick for an upcoming demo. Unfortunately, seeing how our simple approach requires velocities which are very near (or above) the joint limits, we decided to put it aside for the moment until we have a solution which would be less risky for the system.

I could still provide the code we used to generate the speed profiles if it can be of use to the community in this thread. Although, upon verification it is not a minimum jerk trajectory and we are fairly certain that the current limiting factor is, as you mentioned, the voltage applied to the motors.

Thanks again for your help! It allowed us to identify the limiting factor quite rapidly. We can now work on solutions which are better adapted to the iCub.

[pattacini]

Glad to have been of help 😃