Subject:
|
Re: Robotic simulators
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 26 Apr 2005 02:50:50 GMT
|
Original-From:
|
Steve Baker <SJBAKER1@AIRMAILspamless.NET>
|
Viewed:
|
937 times
|
| |
|
|
PeterBalch wrote:
> I worked on this a couple of years ago. Not for Lego but for a Robot Wars
> game. (We failed to get the contract from the BBC.)
As hard as this was - it would only have to have been 'good enough' to
fool the naked eye - and the robots themselves would (presumably) have
been designed by you with only a handful of design variations.
Trying to make a simulation that behaves sufficiently well to be useful
for (say) debugging RCX software would be CONSIDERABLY harder - and making
one where literally any robot design would be allowed would be even harder
still.
> All the 3D simulator does is drop two dice above a table (rendered in
> Direct3D). The dice hit each other and the table, bounce around and
> eventually come to rest. They have all the proper physics: inertia, angular
> momentum, friction, partially-elastic collisions, etc. When I started, I
> thought "I understand the physics - how hard can it be?". Hah! How wrong I
> was.
>
> I chose dice because cubes are pretty simple, convex hulls. Doing Newtonian
> mechanics is easy. The big problem is collisions.
The answer in this specific case would definitely be to use a package
like ODE. It knows how to deal with those kinds of problems.
ODE has other problems though - stability is kinda 'iffy' if you stray
far from the dimensions, masses, inertias and spring stiffnesses they
use in their demo programs.
> It's not neccessary to model the physics exactly. Just so long as the
> result is within 10%. After a few decades living on Earth, it's glaringly
> obvious if objects don't behave properly but 10% is good enough.
That's true if it's for a game - but if you wanted to debug an RCX program,
I don't think that would be good enough.
Also, errors tend to multiply in physics simulations. Something where just
two objects collide against a flat surface isn't likely to suffer too badly
but a robot with perhaps a few dozen moving parts will rapidly develop cases
where 10% errors add up a dozen times and turn into a 120% error.
> You can tell that the dice have collided because they inter-penetrate. But
> then what? Forces are generated but how big and in what direction?
One approach is to backtrack time. So if the two dice were not touching,
then you moved the simulation forwards by a hundredth of a second and found
that they inter-penetrate - then you need to back up time by (say) 1/200th
second and try again. If that's a 'miss' then move time forwards by 1/400th
second. If it's still a hit then back up 1/400th second.
You'll never get to the exact moment of the two cubes touching - but you can
reduce the amount of interpenetration to some arbitary threshold that you choose.
This works for simple situations - and works very well if you have lots of
CPU time to spare...but for realtime simulation of large numbers of objects
that interact, it can get painful.
Another approach is to realise that at time 't' the objects were not touching
and at time 't+1' they were interpenetrating. By calculating how far apart
the most deeply interpenetrating edge was from the nearest surface at time 't+1'
- and figuring back to how far that edge was from that same surface at time 't',
you can arrive at an estimate of when the precise moment of collision was and
back time up to that moment.
Physics simulation is a HUGE and very difficult subject area though.
> That will work 99% of the time but in the remaining 1% of collisions, the
> system goes haywire.
That happens in ODE too. With simple systems, things stay under control
most of the time. But as the system complexity goes up, so the number of
these collisions that happen increases - and so does the number of special
cases (such as three objects interpenetrating each other at the same point
in space).
With complex systems, any tendancy of the math to 'blow up' will be a very
common occurrance.
> It seems to happen when a corner hits an edge or
> another corner. I think it's to do with the corner penetrating one face but
> then approaching another face. The cubes seem to get energy from nowhere
> and whizz off away from each other. You can sometimes see it with other
> people's simulations so it's clearly not a bug specific to my s/w.
There seems to be a nasty trade-off between keeping the system stable, having
good realism and having the calculations run in a reasonable amount of time.
You seem to get any two of three!
> My solution was a "sanity check". If the total kinetic energy after the
> collision is greater than the total kinetic energy before then decrease the
> energy of both objects.
Yeah - those kinds of band-aids work for simple systems - but then you find
that in some more complex situation, they cause peculiar problems of their
own. In your case, I'd anticipate problems with three-way collisions. You
might find that (for example) a block is sliding down a slope, behaving nicely.
Then you bounce a ball on some other part of the slope - nowhere near the block
and because the block/ball/slope system has to lose some kinetic energy, the
block will slow down...for absolutely no obvious reason (but in actuality, to
preserve the kinetic energy incorrectly gained by the bouncing ball.
These kinds of problems are rampant in realtime physics simulations.
> That gave a completely convincing simulation of two cubes but I was
> exhausted. What I thought would take me a couple of days had taken a
> fortnight. and I'd lost my appetite for applying it to simulated robots.
Did your simulation cope with the situation where one cube came completely
to rest sitting on one face of the other cube? Such 'resting collisions'
can be really tricky to deal with because the simulation applies gravity
to the top cube - which causes it to start accellerating downwards. Now
you detect a collision and apply a restoring force - which causes the top
cube to accellerate upwards.
The net result is that the top cube doesn't just sit still - it kinda jiggles
around randomly until it falls off! Applying more band-aids to the math to
take care of this causes other problems with very heavy slow moving objects.
> Beware, it's a deceptive problem.
Well said!
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
Message has 1 Reply:
 | | Re: Robotic simulators
|
| Hey, I really appreciate the input from ppl who have actually worked on this sort of stuff. It happens to be an area I am actively researching, and I'm fascinated by how difficult it seems to be to do good simulations. The consensus seems to be that (...) (19 years ago, 26-Apr-05, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Robotic simulators
|
| Dan and Steve I worked on this a couple of years ago. Not for Lego but for a Robot Wars game. (We failed to get the contract from the BBC.) I have a 2D simulator for the "gameplay" - the computer controlled robots attack, defend, run away and avoid (...) (19 years ago, 25-Apr-05, to lugnet.robotics)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
