Hi, all. Good afternoon. First off, I'm very glad that we're having this second edition
of the Robotics and Simulation Devroom. Also, thank you to the excellent organizations
so far. My name is Agna. I work as a Robotics Engineer at Intermodalix, and today I would
like to share a bit about Modeling Vehicle Dynamics, as well as a little simulator I built.
A quick question, who of you has already used enough to the navigation, rust navigations
taken some capacity? Okay, yes, see quite a few hands, especially there. Yes, a bit of a surprise.
Okay, so I will start with a little, I have slowly related on that, so I was working with
enough to, with a mobile platform in simulation, and everything was progressing really
well, like maneuvers looked nice and efficient, like you see on the dreaded trajectory
on the slide. Then we got real platform out, and something not to the similar from this
blue mess arose. Like maneuvers were at once, like taking twice as long, and it's
a bit weird, because when we compared real platform and to one that we had in simulation,
we had a real platform reacted a bit more slowly, but it wasn't that much difference. What
was actually happening is that the controller was making errors, correcting them, and again,
again, amplifying that little error. Of course, we could spend time at effort and improve
the simulation, though we also ran in some other observations, like, this is what we noticed
once we launched the simulator. And this is without, like, the notes that you want to test,
even learning like we still had to launch enough to, and it gets worse once you start using
your simulation in automated testing, because then you're often not that sure on what
computer you will be running on, or what other tasks will be running on that server,
resulting in failed tests, and that gets really frustrating, really fast. Of course,
those have something for this, it's called useSIMPTIME, though one starts to wonder, why can't
simulation just be efficient and run at world clock, like, any real life system does?
If you look at, like, companies and hobbyists alike, they often see, at least, I often see
is that, like, because a lot of effort and simulation, actually the returns aren't that great,
can be say like, simulation doesn't deliver, and honestly, that's really sad, because I believe
that it can be a formidable tool, and, like, accelerate your development, like, considerably.
So, start thinking a bit, yeah, what can we change to make simulation more accessible? Of course,
some applications have some inherent complexity that weren't all effort, though, what if you,
like, look for a simulator, focused on enough to control a development and tuning?
But can we do? First, I would believe it's important as realistic dynamics, like, I'm fine,
with having to configure a few parameters, but do I really have to go with a thousand
clients, see plus plus plug in for just my four-wheeled, again, one vehicle?
Related to that, like, parameter values, I have my real platform, and no have to put parameter values
in my simulator to represent that platform, which value street I choose, like, how do I go from
from the real life, but for them to assimilate it
that is represented as a related laborious set up,
like for example, some simulators, they rely on putting
parameters in a UHDF.
Now if you want to parameterize your test,
that is not very straightforward.
Something like Rostu parameters would be quite welcome there.
If we're simulating kinematics and dynamics,
maybe can as well do also localization
and using the R1 of 5 map or the basic convention.
And finally, I'd be a bit efficient
back with, like, the just runs on my laptop fine.
Well, basically, these four tanks are the key features
of the new little simulator I wrote,
vehicle dynamics.
I propose that I know, over briefly, what
we're actually modeling, when we look at like a vehicle dynamics,
it gets pretty complicated, pretty fast.
For example, if you have rolling tire and I was to force
on the tire that tire will slip slightly.
And of course, my kin parametrized that,
but those actual parameter values depend on things
like rubber type, raw type, and so on.
Basically, if you don't know the parameter values,
then all that complex model is pretty useless.
In short, I'd make a trade-off between on the one hand,
ease of use, and on the other hand, physical realism.
I chose to go with these three physical effects,
that time acceleration limit, and low pass time constant.
Let's start with the first one, that time.
So this is the duration between your controller
applying a velocity or other reference,
and the system exhibiting a significant response.
Now, in a well-designed system, this is a matter of milliseconds.
So most of the time, they're glitriple.
Though what we actually see is that even like big,
expensive platforms from like big companies,
they have like that times in the range of attempts,
or two times of a second.
And when it's that large, it significantly decreases
your system's stability, and it's also one of the key reasons
for control overshrewed.
Next, acceleration limits.
So your platform has tires, and those can only
exert a finite force on the floor.
And as a result, your acceleration of your platform
is also limited, and that means that it takes some time
to desolarate.
Now, where is this critical?
Well, it's mostly, like it influences the time to stop,
and it's just critical for things like obstacle avoidance,
but also safety in general.
If you want to do safety well, it's really good
to know your acceleration limits.
Finally, the third one, low pass time constant.
So this arises from that the motor controller,
like the velocity feedback controller, it has finite gains,
and it's control output is proportional to the velocity error,
and this gives this like cyan curve.
We see there on the left in the graph.
Overall, it makes the system react a bit slower.
It's a bit similar to that time.
It's more gradual.
Great.
So we have three parameters.
How do we determine them?
Well, good news that's pretty straightforward.
So what we do is, while we take our system,
we apply a velocity set point, like a step reference.
We measure, or velocity using, like,
wheelodometry or something.
We plot it with a two-like plot controller.
Then we will see something very similar to the graph on the left.
And then it's just a matter of, like, taking the,
like measuring the parameters from the graph,
but the manipulation and having the simulation,
something that is pretty similar.
I do normally have little demo video,
and also a little bit of time.
True.
Yes, OK.
Did you download it?
Yes.
No.
OK, no worries.
So normally, there was a demo video.
Of enough, two-bit, you can look at it on the website.
OK.
Thanks a lot, everyone, for your attention.
Thank you.