I'm trying to make some reach-grasp trajectories in timeline. They work fine with the virtual robot. On the real Pepper, sometimes they execute fine, then, next try, the right arm doesnt move in the complete trajectory. If I then use the inspector to move the right shoulder pitch, it gets stuck around 50°.
I wonder if there is some stiffness, or force, parameter: it is as if the robot does not have the strength to make the movement.
You may debug the hand movement with a simple command line Python script that we have made for us. See https://nlp.fi.muni.cz/trac/pepper/wiki/SetArmPosition with a link to souce code.
Pepper has barely the strength to lift its arms when stretched.
When it does so, these motors get hot, and the power fed to them is reduced, to the point where the motion cannot be performed.
Prefer more complex motion, that requires less instantaneous strength to perform, for instance by using a bit of the roll motion, and by stretching the arms only at the last moment.
Related
I have a rather simple react-three-fiber setup that includes cannon.js-powered physics. In the scene there is a cup -- which is modelled as a cylinder whose top radius is bigger than the bottom one -- that is placed on a surface.
When I run the code, during the loading screen everything looks fine. But when physics kick in, the cup suddenly "sinks" into the ground. Why is that? I can't make sense of that...
One theory of mine was that the "physics shape" of the cylinder is not identical with the "optical shape" that gets rendered, but even then the movement I observe still doesn't make sense with any reasonable bounding box I can imagine...
Working example: https://codesandbox.io/s/amazing-proskuriakova-4slpq
Physics are finicky and really hard to debug because you're often trying to intuit the effects of an invisible system by its effects on whatever hybrid view you have.
I notice if i bring the mass downn to a more reasonable value, like 5, the object appears to roll around like a sphere or some other shape.. so I think your theory is sound. I don't know off the top of my head what the solution is, but I do know that the only physics engine I "trust" in the js space, except for very simple simulations, is Ammo.js. It's hard to use, but is an emscripten port of a truly amazing AAA quality library. https://threejs.org/examples/?q=phys#physics_ammo_break
I would start by getting a cube and a sphere working.. once you have verified that those work as expected.. ideally using real-ish world scale units, like a 1x1x1 cube, with a mass of 1. Use a texture on the sphere so you know that its rolling like you expect. Once you have verified the simpler primitives work, move onto the more complex geometries.
Best way forward would be to make an issue on the use-cannon GH. That lib and cannon-es are under active maintenance now. Meanwhile, i believe convexpolyhydron can also do it flawlessly, see: https://codesandbox.io/s/r3f-convex-polyhedron-cnm0s
I'm working on a project where I'm capturing people making free throw shots via a video camera. I need a way to detect, as fast as possible, the instant the ball is released from a player's hand. I tried researching a lot of detection/tracking algorithms, but everything I've found seemed more suited to tracking the ball itself. While I may eventually want to do that, right now all I need to know is the release timing.
I'm also open to other solutions that don't use the camera (I have a decent budget), but of course I'd like to use the camera if possible/fast enough. I'm also able to mess with the camera positioning/setup, and what I even want in the FOV.
Does anyone have any ideas? I'm pretty stuck right now, and haven't been able to find anything online that can help.
A solution is to use visual markers (motion trackers) on the throwing hands and on the ball. The precision is based on the FPS of the camera.
The assumption is that you know the ball dimension and the hand grip on the ball that may vary. By using visual markers/trackers you can know the position of the ball relative to the hand. When the distance between the initial grip of the ball and the hand is bigger than the distance between the center of the ball and it's extremity then is when you have your release. Schema of the method
A better solution is to use a graded meter bar (alternate between black and white bars like the ones used on the mythbusters show to track the speed of objects). At the moment there is a color gap between the hand and the ball you have your release. The downside of this approach is that you have to capture the image at a side angle or top-down angle and use panels to hold the grading.
Your problem is similar to the billiard ball collision detection. I hope you find this paper helpful.
Edit:
There is a powerful tool, that is not that expensive named Microsoft Kinect used for motion capture. The downside of this tool is that it's camera works with 30 fps and you cannot use it accurately on a very sunny scene. However I have found a scientific paper about using kinect to record athletes, including free-throws in basketball. Paper here
It's my first answer on so. Any feedback on how to improve my future answers is appreciated.
So me and my partner are trying to make a pong game that's player vs. computer, but we just couldn't figure out how to make the computer lose.
We already have the basic stuff done and it works fine but the computer just never loses. And we also tried slow down the computer peddle using sleep, but whenever the paddle moves slow, the ball also moves slow.
any advice would help!
Thanks
And we also tried slow down the
computer peddle using sleep, but
whenever the paddle moves slow, the
ball also moves slow.
You need to make it slower by moving it a shorter distance each time it moves.
In the original Pong game, the paddle was perfectly in sync with the ball, that is whenever the ball went down a line, the paddle did too. Obviously, that would make the game unwinnable so the solution used by the developers was to skip an update cycle every few cycles.
In layman's terms, on every frame, you adjust the paddle's location to follow the ball, except on the fifth, tenth, fifteenth, etc. By doing that, your paddle will seem to follw the ball nicely, but with some kind of delayed reaction.
I assume that the computer never loses because it "knows" where the ball is going to go. In that case, why can't you make it go to the wrong place some percentage of the time?
As well, if you just wanted to slow it down, rather than sleeping, you could intersperse "moves" of "don't go anywhere" along with the movement towards what it thinks is the right place to be. So instead of "down 1, down 1, down 1", you could have "down 1, down 0, down 0, down 1, down 0, down 0..." or something along those lines.
I think there is a game site for problems like this https://gamedev.stackexchange.com/. But my answer would be to try and cycle the top speed of the AI bat. And to make the bat short sited. (Only respond to the ball position once it is in its half.)
Computer must make mistakes to lose. The catch is, the mistake must be realistic. If the mistakes seems too artificial, the human player loses interest after a while. The human must believe the cause of the mistake is his good play.
The computer may occacionally react late. I mean, freezes when the human hit the ball. This may especially happen if the human hit the ball with the edges.
Intentional going slow would be unrealistic. But sometimes the computer may go a little bit slower while defending a ball that would bounce.
The computer may plain react to wrong side (for example, go up instead of down) when the ball hit with the middle of the bat.
The computer may wait a ball at the wrong place (off by 1), especially if the ball would bounce.
When you use Sleep the whole program stop for some milliseconds.
Do you have a game loop ? If so, try decreasing the translation amount, and do not forget to normalize
the acceleration vector.
cpuPadlle.Position += amount * acceleration;
Where :
amount in [0..1]
acceleration is a 2d
vector
How can I program hourglass behavior (similar like on picture) for my game?
Should I make something like gravitation and process each grain of sand?
What about digital hourglass (like on this clocks)?
Wasting effort on a "proper" simulation for grains of sand for the sake of an in-game hourglass is serious over-engineering.
Get an artist to produce a high-quality animation and either render it as a series of static images or as a movie.
Seriously, don't simulate the sand.
Tangentially, you can model falling sand with cellular automata. I'd not considered using it for an hourglass simulation, but in principle it might work quite nicely, and be a fun project.
Looking at your digital hourglass -- either the grains move in set patterns, or it might use something like this CA.
Modelling it is making a rod for your own back, you'd be better off just drawing the frames by hand and playing them back.
But -- if maths is your thing you could:
work out the volume of sand in the top.
define a rate of volume flow through the neck (keep this arbitrary as you'll want to tweak it).
at any given time you can use the flow rate to work out how much sand has left the top.
if you know the shape of the top vessel you can work out the current height of sand given the current volume of sand.
if you know the shape of the bottom vessel you can work out the current height of sand given the volume of sand that's flowed through the neck.
I will play devil's advocate here and assume you actually want to simulate sand in your game not just create a simple hour glass loading indicator (as people have said it would be a waste of effort).
So I go back to my initial comment. What kind of resolution are you looking for?
Chances are you don't need to simulate each granule of sand. So keep it simple and leave the physics out of it and just simulate the effect.
For example, off the top of my head you can use 3 simple rules:
Gravity: If the pixel below a "sand pixel" is empty shift that column down.
Cave In: If there is a empty space between two columns of "sand pixels" fill it in if the space below it is not empty (ie. not falling)
Pile Up: if there is empty space beside a column of "sand pixels" spread it out if the space below it is not empty.
These are just some example of rules that might work. The point is to experiment to come up with a simulation that will give the desired effect. Typically it is less work and processor intensive than modeling the physics.
Modern UI's are starting to give their UI elments nice inertia when moving. Tabs slide in, page transitions, even some listboxes and scroll elments have nice inertia to them (the iphone for example). What is the best algorythm for this? It is more than just gravity as they speed up, and then slow down as they fall into place. I have tried various formulae's for speeding up to a maximum (terminal) velocity and then slowing down but nothing I have tried "feels" right. It always feels a little bit off. Is there a standard for this, or is it just a matter of playing with various numbers until it looks/feels right?
You're talking about two different things here.
One is momentum - giving things residual motion when you release them from a drag. This is simply about remembering the velocity of a thing when the user releases it, then applying that velocity to the object every frame and also reducing the velocity every frame by some amount. How you reduce velocity every frame is what you experiment with to get the feel right.
The other thing is ease-in and ease-out animation. This is about smoothly accelerating/decelerating objects when you move them between two positions, instead of just linearly interpolating. You do this by simply feeding your 'time' value through a sigmoid function before you use it to interpolate an object between two positions. One such function is
smoothstep(t) = 3*t*t - 2*t*t*t [0 <= t <= 1]
This gives you both ease-in and ease-out behaviour. However, you'll more commonly see only ease-out used in GUIs. That is, objects start moving snappily, then slow to a halt at their final position. To achieve that you just use the right half of the curve, ie.
smoothstep_eo(t) = 2*smoothstep((t+1)/2) - 1
Mike F's got it: you apply a time-position function to calculate the position of an object with respect to time (don't muck around with velocity; it's only useful when you're trying to figure out what algorithm you want to use.)
Robert Penner's easing equations and demo are superb; like the jQuery demo, they demonstrate visually what the easing looks like, but they also give you a position time graph to give you an idea of the equation behind it.
What you are looking for is interpolation. Roughly speaking, there are functions that vary from 0 to 1 and when scaled and translated create nice looking movement. This is quite often used in Flash and there are tons of examples: (NOTE: in Flash interpolation has picked up the name "tweening" and the most popular type of interpolation is known as "easing".)
Have a look at this to get an intuitive feel for the movement types:
SparkTable: Visualize Easing Equations.
When applied to movement, scaling, rotation an other animations these equations can give a sense of momentum, or friction, or bouncing or elasticity. For an example when applied to animation have a look at Robert Penners easing demo. He is the author of the most popular series of animation functions (I believe Adobe's built in ones are based on his). This type of transition works equally as well on alpha's (for fade in).
There is a bit of method to the usage. easeInOut start slow, speeds up and the slows down. easeOut starts fast and slows down (like friction) and easeIn starts slow and speeds up (like momentum). Depending on the feel you want you choose the appropriate one. Then you choose between Sine, Expo, Quad and so on for the strength of the effect. The others are easy to work out by their names (e.g. Bounce bounces, Back goes a little further then comes back like an elastic).
Here is a link to the equations from the popular Tweener library for AS3. You should be able to rewrite these in JavaScript (or any other language) with little to no trouble.
It's playing with the numbers.. What feels good is good.
I've tried to develop magic formulas myself for years. In the end the ugly hack always felt best. Just make sure you somehow time your animations properly and don't rely on some kind of redraw/refresh rate. These tend to change based on the OS.
Im no expert on this either, but I beleive they are done with quadratic formulas, that, when given the correct parameters, start fast or slow and dramatically increase or decrease towards the end until a certain point is reached.