Add a "locking" fonctionnality to brake

[ShuffleWire]

Is your feature request related to a problem? Please describe.
When working on a moving robot with an arm, often the robot could move a long time without using the arm (for instance to bring a part from a room to another). During this movement, the mechanic on the robot doesn't allows any movement of the arm (like an hydraulic actuator, or a locker).
I'm controlling the arm with speed control, but setting the speed to 0 doesn't forbid to drift from it position, especially if the arm is heavy, or if the robot move fast.
Switching to position control doesn't seems to be the good solution, because it will cause the arm the still move a bit, will consume energy if the robot simulate a battery, required a position sensor to get the current position to "lock on", and it's computationally expensive for something that simple...
Using Brake doesn't do the trick, because it add damping, but don't forbid slow drift from a position.

Describe the solution you'd like
I want to be able to temporarily lock to part relatively one to the other. I don't want any movement, whatever the force could be.
In term of ODE engine, it would be like an implicit solid merging, which could moreover save computation time.
I could be an option on the join, or maybe on the Brake device, as if we were using an "handbrake" in a car.
However, i don't know if it's possible to (un)merge solid dynamically at ODE level. but it could be implemented latter.

Describe alternatives you've considered
For the moment I'm using two connector, on both part I want to lock, and (un)lock the connector when necessary (no snap, no position limitation...). it work well, but add extra complexity I want to get ride of.
I don't know how the Connector work with ODE, or if it's Webots which handle it, but it would be a way to implement something nice, imo.

[omichel]

Did you try to increase the maxTorque/maxForce values of the motors in your arm? That should help the arm keeping its position while being moved.

[ShuffleWire]

It's not, actually.
First, I want to keep the max force i've set, because it's usefull otherwise, to detect if the arm could actually make some move etc...
And even if I set dynamically the force to a very high value when it should not move, It won't fix the issue :
An arm will be pull by the gravity, for instance, and because I'm controlling it with speed control, the following will occurs :
t=0 : arm in position
t = 1dt : gravity pull the arm, thus, the speed of the arm increase a bit
t = 2dt : speed control come into play, to bring the velocity to 0, using max force. Note that the velocity is brought back to 0 (which is what the regulation is looking for), not to an opposite speed to bring the arm in place.
t = 3*dt : gravity pull, and so on...
each small displacement after each small displacement, the arm drift from it position.
Did I get things clear ?
As a side note, i could not risk to get a arm moving even a bit, because I'm using safety system, which, if they detect movement when it shouldn't have any (on the arm), could stop the robot.

[omichel]

That is strange as we have mobile manipulators, like the KUKA robot which doesn't seems to be affected by what you describe. Could you compare your system with the KUKA youbot example and see where does the difference in behavior come from?

[ShuffleWire]

Ok, I will have a closer look. But first, my arm is very heavy (300kg empty, up to 1500kg) and that could make thing difficult for Webots. i've not played enough with ERP parameters, maybe it could help...

[ShuffleWire]

BTW : side question, and mybe could take part of a new issue : speaking of ERP, why ContactProperties use "softERP" ? What is the difference with "ERP" ?

[omichel]

ERP is global whereas softERP is local.

[ShuffleWire]

ERP is global whereas softERP is local.

Very well, but should we change "soft" to "local" it's rather misleading, imo ?
or do we even actually need to differentiate them ? When defined, it's inside a ContactProperties, already...
But it would break compatibility, though... Just a thought passing by ;)

[omichel]

Very well, but should we change "soft" to "local" it's rather misleading, imo ?

No, it is called "softERP" in ODE and we don't want to confuse users with a different naming. ODE has both "ERP" and "softERP" properties, see https://ode.org/ode-latest-userguide.html

[ShuffleWire]

Coming back to this subject after a long time !
AFAIK, the kuka controler use wb_motor_set_position (as in arm_set_height.m), which ensure that internal PID will keep the arm in position.
However, I'm using a speed control on my robot, and setting the speed to 0 is not enough to keep the arm steady, contrary to how behave an hydraulic actuator (when the valve is closed, no flow move, whatever the force)

[omichel]

Speed control is not a good way to keep a position steady. Instead you should rely on position control.

[ShuffleWire]

But my real actuator is controlled by speed control and it internally ensure that this speed is matched precisely. Of course, a control loop on higher level take the responsibility of the position control (I have sensor that give me the length of the actuator). And note that this actuator could by nature ensure steady position.
So in Webots I have to match this behavior.

Yes, I could use a position control and drive it by measuring the current position of the position of the actuator, and deduce the next command according to current velocity requested, but I think it's not the way to go : To get a position control, I will end up doing "Position control" -> "Speed command" -> "Position command", and that heavy, and that without taking in consideration the PID of the position control of Webots, which I would have to setup, and who could cause issues...

I would like to not go that route. In fact my solution work just fine for the moment, I just don't want to miss anything nicer ! :)

[omichel]

I am sorry, but I have no better idea in that case.

[ShuffleWire]

It's actually fine :) My actuators are not a "robotics-ready" one, they behave not like a simple servo. There are many part involved when driving it, and I don't want to dive to much in it. My first task is to get the whole bot running ! :)
The next issue I will have is that they are so powerful that the response curve in speed could be considered independent from the load, and that will be also a pain to deal with in Webots (or any software), I think.
So I think that cheating a bit is fine :)