WEBVTT 00:00.000 --> 00:14.120 Hi, all. Good afternoon. First off, I'm very glad that we're having this second edition 00:14.120 --> 00:19.640 of the Robotics and Simulation Devroom. Also, thank you to the excellent organizations 00:19.640 --> 00:27.520 so far. My name is Agna. I work as a Robotics Engineer at Intermodalix, and today I would 00:27.520 --> 00:34.520 like to share a bit about Modeling Vehicle Dynamics, as well as a little simulator I built. 00:34.520 --> 00:41.000 A quick question, who of you has already used enough to the navigation, rust navigations 00:41.000 --> 00:48.320 taken some capacity? Okay, yes, see quite a few hands, especially there. Yes, a bit of a surprise. 00:48.320 --> 00:53.680 Okay, so I will start with a little, I have slowly related on that, so I was working with 00:53.680 --> 00:59.320 enough to, with a mobile platform in simulation, and everything was progressing really 00:59.320 --> 01:04.960 well, like maneuvers looked nice and efficient, like you see on the dreaded trajectory 01:04.960 --> 01:12.480 on the slide. Then we got real platform out, and something not to the similar from this 01:12.480 --> 01:19.960 blue mess arose. Like maneuvers were at once, like taking twice as long, and it's 01:19.960 --> 01:25.480 a bit weird, because when we compared real platform and to one that we had in simulation, 01:25.480 --> 01:30.520 we had a real platform reacted a bit more slowly, but it wasn't that much difference. What 01:30.520 --> 01:35.680 was actually happening is that the controller was making errors, correcting them, and again, 01:35.680 --> 01:45.320 again, amplifying that little error. Of course, we could spend time at effort and improve 01:45.400 --> 01:52.040 the simulation, though we also ran in some other observations, like, this is what we noticed 01:52.040 --> 02:00.200 once we launched the simulator. And this is without, like, the notes that you want to test, 02:00.200 --> 02:05.720 even learning like we still had to launch enough to, and it gets worse once you start using 02:07.320 --> 02:12.280 your simulation in automated testing, because then you're often not that sure on what 02:12.360 --> 02:16.360 computer you will be running on, or what other tasks will be running on that server, 02:16.360 --> 02:22.360 resulting in failed tests, and that gets really frustrating, really fast. Of course, 02:22.360 --> 02:28.280 those have something for this, it's called useSIMPTIME, though one starts to wonder, why can't 02:28.280 --> 02:34.840 simulation just be efficient and run at world clock, like, any real life system does? 02:34.840 --> 02:44.440 If you look at, like, companies and hobbyists alike, they often see, at least, I often see 02:44.440 --> 02:50.120 is that, like, because a lot of effort and simulation, actually the returns aren't that great, 02:51.480 --> 02:56.520 can be say like, simulation doesn't deliver, and honestly, that's really sad, because I believe 02:56.520 --> 03:02.440 that it can be a formidable tool, and, like, accelerate your development, like, considerably. 03:03.080 --> 03:08.760 So, start thinking a bit, yeah, what can we change to make simulation more accessible? Of course, 03:09.480 --> 03:16.200 some applications have some inherent complexity that weren't all effort, though, what if you, 03:16.200 --> 03:22.920 like, look for a simulator, focused on enough to control a development and tuning? 03:25.080 --> 03:32.040 But can we do? First, I would believe it's important as realistic dynamics, like, I'm fine, 03:32.200 --> 03:38.840 with having to configure a few parameters, but do I really have to go with a thousand 03:38.840 --> 03:45.160 clients, see plus plus plug in for just my four-wheeled, again, one vehicle? 03:47.320 --> 03:53.880 Related to that, like, parameter values, I have my real platform, and no have to put parameter values 03:54.520 --> 04:01.000 in my simulator to represent that platform, which value street I choose, like, how do I go from 04:01.000 --> 04:03.280 from the real life, but for them to assimilate it 04:03.280 --> 04:10.560 that is represented as a related laborious set up, 04:10.560 --> 04:15.560 like for example, some simulators, they rely on putting 04:15.560 --> 04:17.520 parameters in a UHDF. 04:17.520 --> 04:19.400 Now if you want to parameterize your test, 04:19.400 --> 04:21.240 that is not very straightforward. 04:21.240 --> 04:25.000 Something like Rostu parameters would be quite welcome there. 04:25.000 --> 04:28.040 If we're simulating kinematics and dynamics, 04:28.040 --> 04:30.040 maybe can as well do also localization 04:30.040 --> 04:37.280 and using the R1 of 5 map or the basic convention. 04:37.280 --> 04:39.240 And finally, I'd be a bit efficient 04:39.240 --> 04:44.640 back with, like, the just runs on my laptop fine. 04:44.640 --> 04:48.520 Well, basically, these four tanks are the key features 04:48.520 --> 04:51.360 of the new little simulator I wrote, 04:51.360 --> 04:53.400 vehicle dynamics. 04:53.400 --> 04:56.320 I propose that I know, over briefly, what 04:56.320 --> 05:03.320 we're actually modeling, when we look at like a vehicle dynamics, 05:03.320 --> 05:06.880 it gets pretty complicated, pretty fast. 05:06.880 --> 05:10.480 For example, if you have rolling tire and I was to force 05:10.480 --> 05:15.080 on the tire that tire will slip slightly. 05:15.080 --> 05:17.760 And of course, my kin parametrized that, 05:17.760 --> 05:20.600 but those actual parameter values depend on things 05:20.600 --> 05:24.320 like rubber type, raw type, and so on. 05:24.320 --> 05:27.000 Basically, if you don't know the parameter values, 05:27.000 --> 05:30.840 then all that complex model is pretty useless. 05:30.840 --> 05:33.840 In short, I'd make a trade-off between on the one hand, 05:33.840 --> 05:38.880 ease of use, and on the other hand, physical realism. 05:38.880 --> 05:41.920 I chose to go with these three physical effects, 05:41.920 --> 05:47.600 that time acceleration limit, and low pass time constant. 05:47.600 --> 05:50.080 Let's start with the first one, that time. 05:50.080 --> 05:52.880 So this is the duration between your controller 05:52.880 --> 05:56.160 applying a velocity or other reference, 05:56.160 --> 06:00.280 and the system exhibiting a significant response. 06:00.280 --> 06:04.000 Now, in a well-designed system, this is a matter of milliseconds. 06:04.000 --> 06:06.440 So most of the time, they're glitriple. 06:06.440 --> 06:09.840 Though what we actually see is that even like big, 06:09.840 --> 06:13.920 expensive platforms from like big companies, 06:13.920 --> 06:16.600 they have like that times in the range of attempts, 06:16.600 --> 06:18.320 or two times of a second. 06:18.320 --> 06:21.200 And when it's that large, it significantly decreases 06:21.240 --> 06:26.200 your system's stability, and it's also one of the key reasons 06:26.200 --> 06:28.400 for control overshrewed. 06:30.640 --> 06:33.400 Next, acceleration limits. 06:33.400 --> 06:37.000 So your platform has tires, and those can only 06:37.000 --> 06:40.800 exert a finite force on the floor. 06:41.800 --> 06:44.000 And as a result, your acceleration of your platform 06:44.000 --> 06:48.000 is also limited, and that means that it takes some time 06:48.000 --> 06:50.240 to desolarate. 06:50.240 --> 06:52.560 Now, where is this critical? 06:52.560 --> 06:57.360 Well, it's mostly, like it influences the time to stop, 06:57.360 --> 07:00.720 and it's just critical for things like obstacle avoidance, 07:00.720 --> 07:03.960 but also safety in general. 07:03.960 --> 07:06.680 If you want to do safety well, it's really good 07:06.680 --> 07:10.320 to know your acceleration limits. 07:10.320 --> 07:15.920 Finally, the third one, low pass time constant. 07:15.920 --> 07:20.360 So this arises from that the motor controller, 07:20.360 --> 07:24.600 like the velocity feedback controller, it has finite gains, 07:24.600 --> 07:30.960 and it's control output is proportional to the velocity error, 07:30.960 --> 07:36.440 and this gives this like cyan curve. 07:36.440 --> 07:40.080 We see there on the left in the graph. 07:40.080 --> 07:42.960 Overall, it makes the system react a bit slower. 07:42.960 --> 07:45.200 It's a bit similar to that time. 07:45.480 --> 07:48.560 It's more gradual. 07:48.560 --> 07:49.000 Great. 07:49.000 --> 07:51.280 So we have three parameters. 07:51.280 --> 07:53.600 How do we determine them? 07:53.600 --> 07:56.840 Well, good news that's pretty straightforward. 07:56.840 --> 07:59.600 So what we do is, while we take our system, 07:59.600 --> 08:06.080 we apply a velocity set point, like a step reference. 08:06.080 --> 08:08.760 We measure, or velocity using, like, 08:08.760 --> 08:10.440 wheelodometry or something. 08:10.440 --> 08:13.800 We plot it with a two-like plot controller. 08:13.800 --> 08:18.160 Then we will see something very similar to the graph on the left. 08:18.160 --> 08:24.160 And then it's just a matter of, like, taking the, 08:24.160 --> 08:26.840 like measuring the parameters from the graph, 08:26.840 --> 08:29.440 but the manipulation and having the simulation, 08:29.440 --> 08:31.800 something that is pretty similar. 08:36.000 --> 08:38.000 I do normally have little demo video, 08:38.000 --> 08:39.640 and also a little bit of time. 08:40.640 --> 08:42.640 True. 08:42.640 --> 08:43.640 Yes, OK. 08:47.640 --> 08:48.640 Did you download it? 08:48.640 --> 08:49.640 Yes. 08:49.640 --> 08:50.640 No. 08:50.640 --> 08:51.640 No. 08:51.640 --> 08:55.640 OK, no worries. 08:55.640 --> 08:56.640 So normally, there was a demo video. 08:56.640 --> 09:01.640 Of enough, two-bit, you can look at it on the website. 09:01.640 --> 09:02.640 OK. 09:02.640 --> 09:05.640 Thanks a lot, everyone, for your attention. 09:09.640 --> 09:10.640 Thank you.