Partially related to this post, suppose I have a robot with both fixed joints and free joints (ex: separate legs and arms), and I only want to solve InverseKinematics for one of the legs while keeping the other leg and arms fixed as obstacles.
My initial attempt to "fix" the other legs/arms was the following:
Ignore their self-collisions, which assumes their current joint configurations were valid
AddBoundingBoxConstraint on those joints tightly around their current joint configurations
This works, but significantly increases the runtime. Is there any way to modify the plant/internal tree to do this instead? This should really be speeding up the optimization rather than slowing it down.
Nonlinear programs are finicky, but I also would have thought that both adding bounding box constraints to fix joints, and removing collision constraints should speed up inverse kinematics.
We do have a few open issues about runtime remodeling of multibodyplant. https://github.com/RobotLocomotion/drake/issues/13291 and https://github.com/RobotLocomotion/drake/issues/12703, for instance.
Short of that, we did introduce the ability to lock / unlock joints and free-bodies for simulation. It would be a reasonable PR / request to also use MultibodyPlant::EvalJointLockingIndices in the inverse kinematics code to avoid making those decision variables entirely. But I fear that the difference between this and the bounding box constraints should not be very big; probably fixing the joint is putting you into a more troublesome part of the optimization landscape?
Related
An issue arises with contact modeling in robotics simulation package drake.
I try to position-control an iiwa manipulator to affect a body, attached to a screw joint.
What I expect is the nut progressing downwards. What I see is the end-effector sliding around the nut, unable to induce a nuts rotation along the bolt.
note: This is a continued investigation into this question.
The simplifying experiment is to use ExternallyAppliedSpatialForce, instead of the manipulator.
I apply torque around the bolts's Z axis in the centre of bolts axis. The amount of torque is 1 Nm. And, this produces the desired effect:
Then, I stop artificial force application, and try manipulation again, combined with the contact visualization by ContactResultsToMeshcat:
I also print the contact force magnitudes. Forces are in the range of 50-200 N.
But the nut does not move.
My question is, where to take the investigation next, when the 1 Nm torque is able to turn a screw joint, while the 200N force cannot?
So far, after watching 10 repeats of the visualization, I notice that only one finger of end-effector is in contact at any given moment. So, I think, I must prepare less sloppy trajectories for the fingers of end effector [and for the whole arm, for that matter].
It could be the inverse dynamics controller used in ManipulationStation, which is different from (and softer than) iiwa’s real controller, that’s making the robot’s joints too soft and unable to turn the nut.
Specifically, the inverse dynamics controller scales the joint stiffness matrix by the mass matrix of the robot, whereas iiwa's real controller does not do that.
The problem most likely was in having actuation port of bolt-and-nut model not connected to any input port and hence not simulated properly (more details here).
After fix the simulation looks that way:
I'm hoping to simulate the movement of a train along a fixed path. The path itself is representable by a CGPath.
So far, I've found SKPhysicsJointSliding, which seems close, but appears to only work along a fixed axis, and since my path has curves that seems like a deal breaker.
I know I could use a series of SKActions to accomplish the movement, but in my case it's far preferable to have the physics engine handle the movement for me.
My question is basically whether or not this is something the SpriteKit physics engine can accommodate via something I've missed in the documentation (or if I'm somehow misunderstanding the sliding joint)?
Why is "physics" more preferable? Once you're on rails, you aren't really utilizing the physics engine. If you're looking for semi-realistic y-axis yaw as it rumbles down the track, try doing a random rotation about that axis.
You could also try utilizing the SKNode.physicsBody as well. According to Apple's docs, your SKNode doesn't participate in physics simulations until you attach one.
https://developer.apple.com/documentation/spritekit/sknode/1483117-physicsbody
Giving it mass and other physical properties could simulate slowing down, speeding up, etc.
Otherwise, you will have to do a lot of complicated math to apply physical forces in the direction you want the train to go.
Please check the attach image it's a kind of seesaw. But as from image the black bodies have same density. And the horizontal rectangle is attached with the triangle using "Revolute" joint. But still not working any suggestion. in the current situation it's need to be balanced.
Due to tiny imbalances in the layout caused by the limitations of floating point precision etc, it's highly unlikely that this will ever balance in the middle reliably (just like real life). One thing you could try is to give the beam some angular damping, which would make it less easy to swivel around, so it would slow down quicker and sleep earlier. That might be enough to get it to come to rest without falling to one side or the other.
I don't think it is the problem of floating point precision. At least it can't appear that fast. As far as I know Box2D resolves contacts (including resting contacts) one by one. It is much faster than simultaneous contact resolve, but less precise at the same time since resolving one contact create impact on the others.
I would try adding a motor with a small maximum torque to your revolute joint and controlling it's speed to balance the system.
I am wondering how beautiful is "Contre jour" game for IOS.
Especially i like elastic "tentacles",shown in this video on 2 min 20 seconds:
http://www.youtube.com/watch?v=ptdTdJarWLw
How can I implement such effects?
I know that there is technic called "Verlet integration" and even implementation of "verlet rope" for drawing ropes in cocos2d, but how to make such nice elastic effects to "tentacle" sprite?
I have experience of box2D usage, and may try to implement physics for this effect, but cann't find a solution how to draw sprite with such elastic morphing.
Can anybody help me or give some hints?
Just even explanation of technics, that can help me?
I have a little of experience in opengl, great cocos2d experience, so I plan to use cocos2d.
Sorry for bad english, I hope, you will understand my problem:)
If you use Box2D, you could try a distance joint with the frequencyHz and dampingRatio options set to non-default values. Perhaps a low frequency of around 4-6, and a damping of around 0.5-0.7 could be a good point to start from. You could think of frequency as how many times per second the joint tries to correct the distance, and damping as how well the distance is corrected each time. Setting the damping to a value lower than 1 will means the joint will be slower to correct the distance, and it will have a springy/rubbery behavior.
As for rendering, you could indeed use verlet integration for this. Take the two anchor points of the distance joint as the endpoints of the 'rope', and put a handful of points (doesn't look like too many would be necessary) in between them in an evenly spaced line. Every timestep, the points in between will simply move towards the average of the two points on either side of themselves. You could make the rope look tighter or looser by adjusting how far the inbetween points move to the target position each time step.
The final texture/sprite rendering would then take its position from the current location of the verlet points.
I have a field filled with obstacles, I know where they are located, and I know the robot's position. Using a path-finding algorithm, I calculate a path for the robot to follow.
Now my problem is, I am guiding the robot from grid to grid but this creates a not-so-smooth motion. I start at A, turn the nose to point B, move straight until I reach point B, rinse and repeat until the final point is reached.
So my question is: What kind of techniques are used for navigating in such an environment so that I get a smooth motion?
The robot has two wheels and two motors. I change the direction of the motor by turning the motors in reverse.
EDIT: I can vary the speed of the motors basically the robot is an arduino plus ardumoto, I can supply values between 0-255 to the motors on either direction.
You need feedback linearization for a differentially driven robot. This document explains it in Section 2.2. I've included relevant portions below:
The simulated robot required for the
project is a differential drive robot
with a bounded velocity. Since
the differential drive robots are
nonholonomic, the students are encouraged to use feedback linearization to
convert the kinematic control output
from their algorithms to control the
differential drive robots. The
transformation follows:
where v, ω, x, y are the linear,
angular, and kinematic velocities. L
is an offset length proportional to the
wheel base dimension of the robot.
One control algorithm I've had pretty good results with is pure pursuit. Basically, the robot attempts to move to a point along the path a fixed distance ahead of the robot. So as the robot moves along the path, the look ahead point also advances. The algorithm compensates for non-holonomic constraints by modeling possible paths as arcs.
Larger look ahead distances will create smoother movement. However, larger look ahead distances will cause the robot to cut corners, which may collide with obstacles. You can fix this problem by implementing ideas from a reactive control algorithm called Vector Field Histogram (VFH). VFH basically pushes the robot away from close walls. While this normally uses a range finding sensor of some sort, you can extrapolate the relative locations of the obstacles since you know the robot pose and the obstacle locations.
My initial thoughts on this(I'm at work so can't spend too much time):
It depends how tight you want or need your corners to be (which would depend on how much distance your path finder gives you from the obstacles)
Given the width of the robot you can calculate the turning radius given the speeds for each wheel. Assuming you want to go as fast as possible and that skidding isn't an issue, you will always keep the outside wheel at 255 and reduce the inside wheel down to the speed that gives you the required turning radius.
Given the angle for any particular turn on your path and the turning radius that you will use, you can work out the distance from that node where you will slow down the inside wheel.
An optimization approach is a very general way to handle this.
Use your calculated path as input to a generic non-linear optimization algorithm (your choice!) with a cost function made up of closeness of the answer trajectory to the input trajectory as well as adherence to non-holonomic constraints, and any other constraints you want to enforce (e.g. staying away from the obstacles). The optimization algorithm can also be initialised with a trajectory constructed from the original trajectory.
Marc Toussaint's robotics course notes are a good source for this type of approach. See in particular lecture 7:
http://userpage.fu-berlin.de/mtoussai/teaching/10-robotics/