Joint velocity can not be controlled using SetVelocity()

[osrf-migration]

Original report (archived issue) by nima shafii (Bitbucket: nima_sh).

---

In my test, In Robocup3dsPlugin.cc , by using the following commands joints velocity can not be controlled to be Zero.

#!c++

model->GetJoint(kv.first)->SetVelocity(0, 0);

In order to test, after running the simulator, a Robocup team binary can be downloaded from this link, and run the whole team using the following command:

#!linux

./start.sh localhost

[osrf-migration]

Original comment by nima shafii (Bitbucket: nima_sh).

---

In rev 905b2a4dfb39f33ebeebcbca6dd1ab4ad3b60a2e, the joints are controlled using PID controllers on joint angular position, I could not control the velocity using the velocity Controllers. Maybe because the nature of the velocity controlling is more difficult than position controlling and I could not find its correct PID values. Finally I could not control the velocity, so I approximated the joints position based on the input effector target velocity and control the position. I don't know if this solution is correct and it needs more test. In this version the robot only executes the head movements command and simulator keeps the position of the other joints to be zero, as a test, in play_on, the simulator sets new arm position for the robot to move down its arms.

[osrf-migration]

Original comment by jasonzliang NA (Bitbucket: jasonzliang).

---

Hey Nima, once you have fixed all the bugs, could you submit a pull request to the jliang_model branch? Thanks.

[osrf-migration]

Original comment by nima shafii (Bitbucket: nima_sh).

---

Hi jason, yes definitely, more fixed: rev 0fd744e8f3c9b8decf867ac94ad84b4cc9b67b8b

[osrf-migration]

Original comment by jasonzliang NA (Bitbucket: jasonzliang).

---

Hey Nima,

In jliang_model, I have updated Effector.cc so that it checks that numeric values are valid during parsing. For example, "(init (unum lkfjalsdfk) (team left))" would not longer work. Before since we were using atof, parsing non numeric strings would lead to undefined behavior. I changed it so that we are using strtod instead.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Joint::SetVelocity and Joint::SetPosition seem to override the physics engine, that is, that value will be set and all other dynamics effects, such as gravity, will be ignored - which is probably not what we want.

[osrf-migration]

Original comment by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

---

• changed state from "new" to "resolved"

As far as I know this is not an issue anymore because we use JointController::SetPositionTarget() to control the joints. Reopen if it's not the case.