Problems with many-jointed robot
Posted: 06 Sep 2013, 23:53
Hello again,
I'm having a bit of a problem with joints again, that probably still has its origin in scaling and engine parameters. I've twiddled the settings quite a bit here, but whenever I suppress one problems, I'll come up with another.
I recently posted about a two-joint rotational spring & damper leg structure for a robot; I'm not trying to fit that onto a robot body to replace solid rigid-body models of the legs imported from CAD.
Here's the scene:
https://www.dropbox.com/s/b46vmw6c1mrqg ... nglegs.ttt
Up until now, I was having problems with the joints falling apart. By changing some of the masses (design consideration #8) and simulation parameters, the joints seem to hold better.
Now I observe an instability, where the small jitter in the joints is giving rise to a large body motion with no other drive present; it's "skating" due to the jitter. The expected behavior is for the robot to just stand in place, with the legs damping out the initial drop.
Also, take a look at the top view, Page 6. There are graphs there that should be showing the torque at the joints, but it just appears to be noise with not much variation; I'm surprised to see this, consider that graphically, the legs can be seen deviating in position and returning to their controlled position.
I'm not sure what the best choices for ERP, CFM, and fudge factor for the joints and globally are in a situation like this; I would favor "hard" constraints and a slower solution over a faster method that allows accuracy in the joints to decline too far.
Note that there is a fairly complicated script attached to it that is intended to drive some of the body-connected joints through a specific motion profile, with adjustable phase and frequency. That should be largely disabled for this case, where frequencies are set to zero, and thus target velocities are zero to zero and target positions are set to constant.
The part that IS active is where all the joint Kp, Kd, and Ki gains are set in for loops, so it's all localized to one location.
So, if the Coppelia folks or anyone else with eyes on this might have some insight into how to get this simulation to behave properly, or at least more properly than the state I have it in now, any insight would help greatly. This is all going to be open source, too, so it could be available as an example, once it works a bit better.
I'm having a bit of a problem with joints again, that probably still has its origin in scaling and engine parameters. I've twiddled the settings quite a bit here, but whenever I suppress one problems, I'll come up with another.
I recently posted about a two-joint rotational spring & damper leg structure for a robot; I'm not trying to fit that onto a robot body to replace solid rigid-body models of the legs imported from CAD.
Here's the scene:
https://www.dropbox.com/s/b46vmw6c1mrqg ... nglegs.ttt
Up until now, I was having problems with the joints falling apart. By changing some of the masses (design consideration #8) and simulation parameters, the joints seem to hold better.
Now I observe an instability, where the small jitter in the joints is giving rise to a large body motion with no other drive present; it's "skating" due to the jitter. The expected behavior is for the robot to just stand in place, with the legs damping out the initial drop.
Also, take a look at the top view, Page 6. There are graphs there that should be showing the torque at the joints, but it just appears to be noise with not much variation; I'm surprised to see this, consider that graphically, the legs can be seen deviating in position and returning to their controlled position.
I'm not sure what the best choices for ERP, CFM, and fudge factor for the joints and globally are in a situation like this; I would favor "hard" constraints and a slower solution over a faster method that allows accuracy in the joints to decline too far.
Note that there is a fairly complicated script attached to it that is intended to drive some of the body-connected joints through a specific motion profile, with adjustable phase and frequency. That should be largely disabled for this case, where frequencies are set to zero, and thus target velocities are zero to zero and target positions are set to constant.
The part that IS active is where all the joint Kp, Kd, and Ki gains are set in for loops, so it's all localized to one location.
So, if the Coppelia folks or anyone else with eyes on this might have some insight into how to get this simulation to behave properly, or at least more properly than the state I have it in now, any insight would help greatly. This is all going to be open source, too, so it could be available as an example, once it works a bit better.