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.
Related
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?
EDIT: I found ELSD and am going to give it a shot, but any advice would still be appreciated.
EDIT2: The online demo of ELSD works nicely on this problem but the source is in C. Porting it is beyond me.
I am trying to detect postmarks on vintage postcards such as these:
I can spend a few minutes to tweak the cv2.HoughCircles parameters until the postmark is one of a few circles detected... for one scan, but the next card needs entirely different parameters to detect its postmark. At this point, it would a few be orders of magnitude faster to do this manually.
Part of the problem is that the handwriting is often detected as circles, I assume when enough of the curves in the cursive happen to have a similar center point. For whatever radius ranges I use to discriminate there always seems to be something in the handwriting that is detected as a false positive.
Another problem is that the circle often overlaps with other things, such as the stamp or handwriting.
Lastly, the circle part of the stamp is more often than not incomplete.
Is there an alternative to the GHTG method I could use? Perhaps something that checks how much of a continuous circular arc is present without interruption? (While the mark circles are often incomplete, they usually have at least pi radians visible.) Or something that checks for perfect circularity? Less efficient is just fine, as long as it reliably detects real partial-circles without (m)any false positives.
I am building a robot (2 powered wheels and one ball bearing). The problem is that I can't seem to make it drive straight. I literally find it impossible, I have been trying for weeks.
Currently I am able to rely on rotations (of both motors) or the gyro readings(I also have two gyros, each near the two tyres)
Is there a way I can fuse those together, giving me a more accurate way to determine which motor I need to speed up?
My motors accept a value from 0-900 (although the speed should be determined by me and not fixed). Also if an algorithm exists, I'd like some directions of what I'd need to swap if I make the motors go backwards.
The problem of the robot not going straight because the rotation speeds of the two motors might be different. E.g one might be completing 30 rotations per second and the other 31. Trivially this is solved using a wheel encoder. Using that you get the difference of rotation of two wheels and then change the motor speeds accordingly. Gyro can give you angular error per unit time, e.g if robot is moving 5 degree on the left after 2 seconds,then the right motor speed is to be decreased. But how much it needs to be decreased is not a trivial problem, because ultimately it happens because of hardware error. So what you can do is collect some data of the gyro angles, maybe 10 readings per second and analyze the data to find just how much you need to decrease the speed of one motor.
I'm writing a game for sphero, the robotic ball (having issues with their forums, can't seem to ask a question). I'm trying to do ball to ball collision detection for 2 or more players.
first of all the they give a sample here:
https://github.com/orbotix/Sphero-iOS-SDK/tree/master/samples/CollisionDetection
The thresholds they supply are WAY too sensitive, on a wooden floor it triggers all the time. Forgetting that for the minute, I have to use the impact timestamp from both devices to see if they have triggered collisions at roughly the same time.
My issue is when subtracting timestamps, in some cases i'm getting very wide variations and i think the difference is quite long to begin with. I'm storing several timestamps so I don't miss the correct one and I tried playing with the dead time to see if lowering it would help.
Most commonly subtracting 2 NSTimeIntervals i get a difference between 0.68 and 0.72 (I would have expected 0.01 level reactions). So Im checking if the difference is under 0.72, 3 times in a row i got between 0.72 and 0.73, several times I got 1.5, 2.6, 1.1 and even 3.8.
It doesn't seem as though its reliable. The documentation says this time comes from the iPhones reference. Both devices are synced to get time automatically, so they are as close to each other as possible.
Has anyone tried this and come up with a reliable solution, that doesn't involve keeping one ball still ?
I did a significant amount of research on the subject of ball to ball collisions when I started as a developer for Orbotix, the makers of Sphero.
This is a very complicated problem to solve. The closest I came to making this work (for a infected zombies research game) was about 80% accuracy for detecting which ball hit which ball with a sample size of 3. The more balls you would put into the game, the lower the accuracy would become. Hence, we decided to eliminate the issue by having one ball required to stop moving before it was vulnerable, like in Sphero TAG.
There are a few factors that limit this capability, and it seems you have discovered them. I believe the biggest issue is that collision detection has poor performance while the ball is driving. Especially on a rough surface or when the ball makes quick jerky movements. This alone causes majors problems when coupled with the dead time.
I was able to get collision timestamps to within 50 ms on average. Are you taking into consideration the wifi latency in transmitting the packets between phones?
The solution is something you probably don't want to hear, but you should tweak your game play to work within the capabilities of collision detection. That is, the ball driving really slow when it can be contacted, or even come to a stop like in TAG. Ask yourself, how can I make this fun without ball to ball collisions?
I just want to say, first, that we are moving our developer support forum here, to StackOverflow, and that's why you can't post on the forums. So, you did the right thing, Simon, by coming to StackOverflow, and you should be proud.
We just changed the forums to redirect here instead of leaving people confused.
The timestamps are generated by Sphero. But they only make sense is you're using the Poll Packet Times command to generate delay and offset values. Please refer to DID 00h, CID 50h in the API commands document.
That being said, collision detection is an ever evolving technology from our end. We employ a cleverly coded DFT frequency transform on a sliding data window real-time inside the robot. The parameters allow tuning to the surface you're running on; there are no universal settings. If you're obtaining too many false positives then please experiment. If you have ideas to improve the algorithm then contact us directly and maybe we can include it as a new filtering method. We're always open to clever ideas!
You could sync the internal timers of each Sphero at the beginning of the game. These can be matched against a synced timer within each host phone. Clocks may be different, but a millisecond is a millisecond. You could also lower the threshold of the collision detection, thus making it so that the 'event' (damage, infection, etc.) can only occur if the 'attacking' Sphero is moving at a certain speed. Or a variation thereof.
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.