Subject:
|
Re: Robotic simulators
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 26 Apr 2005 06:31:47 GMT
|
Original-From:
|
dan miller <danbmil99@yahoo^SayNoToSpam^.com>
|
Viewed:
|
1210 times
|
| |
|
|
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 you can do a decent job on a well-constrained
problem, like a particular robot or aircraft, at particular speeds, with
known terrain or external conditions. It sounds like the problems mulitply
when you try to make your system general enough to cover unexpected, novel
situations. Not too different from software engineering problems in general
-- it's always the odd cases that get you.
This actually answers a question I've had for years. Whenever I've been
caught up in a good 3D videogame, I've always wanted a more open-ended
system -- where I could totally customize my characters & vehicles, add new
terrain models and so on. Now I get the sense that with present-day tech,
that just wouldn't be possible. The system has to be tuned, and letting the
user change too many things is intrinsically dangerous.
Anyway this is all food for thought, and I doubt I'll be writing this
program anytime soon as I have a family to feed, and I spend enough time
monkeying around with Lego as it is. At least my curiousity as to why it
hasn't been done is somewhat satisfied.
And yet, I sure do love a challenge... (constitutional problem)
-dbm
--- Steve Baker <sjbaker1@airmail.net> wrote:
> 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 is in Reply To:
 | | Re: Robotic simulators
|
| (...) 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 (...) (20 years ago, 26-Apr-05, to lugnet.robotics)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
