MVSim development (Borys Tymchenko)

[jlblancoc]

Initial description:

Many contemporary robotic applications need precise simulation and prognosing of system dynamics. Making a lightweight application that is tailored to analysis of vehicle dynamics and accurate simulation of typical robot will allow developers simple workflow with simulated robotics systems.

See attached PDF. 4899176547614720_1491160723_GSoCMultiplevehiclesimulator.pdf

Code results:

• mvsim PR#5
• mvsim PR #10
• mrpt_navigation PR #79

[jlblancoc]

Student: @spsancti

Main mentors: @FranciscoJManasAlvarez, @torresmoreno, @jhervas79 Backup mentors: @jlblancoc, @EmilioSanjurjo

[torresmoreno]

Hi @spsancti, This is Jose Luis Torres (aka simply Torres). I will be your co-mentor in MVSim development project along with @FranciscoJManasAlvarez and @jhervas79. I work as a professor at the University of Almeria (UAL) and my research lines focus on Multibody Dynamics, with main attention to vehicle dynamics. For more information about my work you can visit my personal website (in Spanish):

It is my pleasure to participate of this program, and I hope you to enjoy the experience.

Cheers.

[FranciscoJManasAlvarez]

Hi @spsancti, I'm Francisco José Mañas (but you can call me Kiko). I'm student at final year of electronic industrial engineering. Now, I'm working in my final career proyect about the control of electric car. I hope that I can help you when it necessary and you can take advantage of this program. Regards

[spsancti]

Hi @torresmoreno, @FranciscoJManasAlvarez It's a great plasure for me to be selected and to work on this project. I hope, it will be a great working experience for me. I will start digging into mvsim code this week, based on this I'll figure out mode detailed work plan.

Cheers.

[jlblancoc]

Hi @spsancti , and, again, welcome to GSoC! ;-)

Let me summarize some remarks for you and the rest of mentors to be on the same page...

First, the present implementation of mvsim uses a philosophy like this:

• We have 1,2,... motors on each vehicle.

• We can control the torque on each motor. At present there is a very simple controller (if I recall it right, it's the simplest proportional-controller ever) that takes a setpoint for axis velocity and generates the torque having as feedback the axis (wheel) speed.

• Then, we have a theoretical dynamics model for each axis/wheel, that includes its inertia, the wheel-ground reaction forces, the motor action, and the reaction of the wheels axis with the vehicle chassis. Its current implementation is here.

• The evaluation of forces at each wheel is here.

• Obviously, there is much room for improvement and for designing better models. In particular, I'm worried with the lack of rolling resistance, which is a fundamental thing to have in the simulator.

• so, what are the first steps, in my view? It would be great to start a LaTeX document that summarizes all of the above, but with a proper mathematical typesetting and description. In my experience, just doing that (writing things down) normally helps to detect errors and gives opportunities for new ideas.

• You can start such a draft document in your fork of mvsim, in a doc directory, and you can use this example in MRPT as a template to have the Latex document built with make, etc. Naturally, only the sources should be added to Git, and, perhaps, the final PDF for the convenience of a casual user who quickly wants to have a look at the doc without compiling it.

Do you think I missed something important? Thoughts?

[spsancti]

Hi @jlblancoc ! Some questions so far:

• What do we need first: wheel speed or wheel torque? Perhaps, it could be more convenient to use torque in some models.
• Do we always have direct drive from motor to wheel?
• What can the motor type be? For DC motors, torque is linear to velocity and non-linear for combustion engines.

After implementing rolling resistance, it would be interesting to implement tire deformation. It is a big issue for even medium-speed robots when calculating wheel slipping.

Now I'm starting to summarize everything into LaTeX document. With the doc, I will make an UML just for convenience, it's always better to have graphical representation.

Any other thoughts?

[torresmoreno]

Hi @spsancti The idea is to use wheels torques and electric motors considering a gear ratio at a first approach. Eventually, we can use any tire model as namely Pacejka's.

It is a good idea to document the work in progress using latex. Actually, @jlblancoc is preparing our server for Sharelatex. We will send you an invitation whe everything is ready.

Cheers

[jlblancoc]

Hi, So far, all seems good!

In addition to JLT comments:

Do we always have direct drive from motor to wheel?

At present, yes. But obviously, a differential driven model (i.e. one motor driving an Ackermann configuration) would require a different dynamical model, where the two wheels must be taken into account into the same "free body diagram", etc. It would be really useful to help simulating slippage when, e.g. one wheel slips while the another does not.

Now I'm starting to summarize everything into LaTeX document. With the doc, I will make an UML just for convenience, it's always better to have graphical representation.

Great!! :+1:

JLT:

Actually, @jlblancoc is preparing our server for Sharelatex. We will send you an invitation whe everything is ready.

Actually... I would recommend going on with the traditional approach... installing Sharelatex is becoming suck a huge p* in the a!!! Really frustrating...

[jlblancoc]

Hi @spsancti , How are you doing with the study of the source code and the theory? Any doubts or comment so far? Have a nice weekend

[spsancti]

Hi, @jlblancoc , So far so good, your approach is very similar to mine at work. Why didn't you use velocity form of PID? As to me, it's more convenient in modelling. Also, LaTeX syntax in more sophisticated than I expected :D For now a little pause - preparing for a test in the university.

[torresmoreno]

Hi @spsancti Feel free to implement any additional kind of controller for velocity. For LaTeX, I recommend you to use TeXstudio. Once you get used to it, you will find it quite easy: http://texstudio.sourceforge.net/ What about your test for University? If you are available now, you can start coding before May ends, just in case you will need any vacation/week of unavailability eventually, etc.

Cheers

[spsancti]

Hi! Test passed, returning to work.

@torresmoreno I'm using texmaker, looks nice. I will have 1-2 days off around 2nd of June.

@jlblancoc , do we have weight transfer somewhere? Looks like sufficient thing to have, unless the speed is too low that it's negligible. Also, what about other sensors than LiDAR?

[jlblancoc]

Nope, no weight transfer so far... it could be added to the long list of things to add to make the lib more realistic!

[jlblancoc]

On sensors, I was thinking of cameras, which should be relatively straightforward by reusing pieces by mrpt-opengl... There is already one class to do off-screen rendering, that would fit this propose perfectly. Can't look for it right now, I'm on the phone, let us know in you have problems localizing it.

Cheers... and congrats for the passed test!

[spsancti]

Hi, Sorry for long silence - got distracted with CMake issue. Sorted out LaTeX things and described friction model. Now things will go easier. Now I'm ging to describe vehicle dynamics. Also, generated some Doxygen; beautiful but not so informative.

I haven't found corresponding opengl class, maybe didn't look good enough.

Do we need some wheels suspension model? It's negligible in small robots, however, to design something more big and sophisticated it's a viable thing to have. Also, it's an interesting task coupled with weight transfer.

[EmilioSanjurjo]

Hello everyone,

My name is Emilio Sanjurjo, from the University of A Coruña. I was supposed to be mentoring this project, but finally I couldn't do it, so I am simply reading your mails as a passive observer. I say this in first place because I would like to share some ideas with you, but I understand if you all simply ignore them.

If I understood well the idea of the MVSim project, it is aimed at having very simple models of robots for low-speed simulations, and hence it uses a 2.5d model (2d model + wheel's rotations). This kind of model does not naturally consider phenomena like weight transfer nor suspensions. If considering these phenomena is important, my personal feeling is that a full 3d multibody simulation will be a better approach, instead of starting from the very simple 2d model and adding complex models on top of it. In the end, these robots are not so different from other kind of vehicles.

That said, I think that the aims of the project must be specified as soon as possible, and if 3d effects are to be included, I personally would start from a multibody model, but remember that this is only an opinion from an external observer.

Regards.

Emilio Sanjurjo Maroño

Mechanical Engineering Laboratory , University of A Coruña. http://lim.ii.udc.es/index.en.html C/ Mendizábal s/n, 15403, Ferrol, Spain.

----- Mensaje original -----

De: "Borys Tymchenko" notifications@github.com Para: "MRPT/GSoC2017-discussions" GSoC2017-discussions@noreply.github.com CC: "EmilioSanjurjo" emilio.sanjurjo@udc.es, "Mention" mention@noreply.github.com Enviados: Martes, 30 de Mayo 2017 11:58:20 Asunto: Re: [MRPT/GSoC2017-discussions] MVSim development (Borys Tymchenko) (#2)

Hi, Sorry for long silence - got distracted with CMake issue. Sorted out LaTeX things and described friction model. Now things will go easier. Now I'm ging to describe vehicle dynamics. Also, generated some Doxygen; beautiful but not so informative.

I haven't found corresponding opengl class, maybe didn't look good enough.

Do we need some wheels suspension model? It's negligible in small robots, however, to design something more big and sophisticated it's a viable thing to have. Also, it's an interesting task coupled with weight transfer.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

[spsancti]

Hi, @EmilioSanjurjo !

It looks like right things to adhere. However, isn't weight transfer important for slow robots when moving on inclined surfaces? And what about suspension of big slow robots on uneven terrains (like automated lawn mowers)?

As to me, with 3D multibody model, it's better to start from scratch and it will definitely take more time than 3 months. Also, there is Gazebo for this purpose.

@torresmoreno , @jlblancoc , what do you think of it?

[jlblancoc]

I definitively have an idea on how to deal with this.

My baby was born a few days ago and I'm really busy, funny days! :-)

Will catch up with all the gsoc projects asap guys...

[EmilioSanjurjo]

Hi Borys.

Yes, you are right, weight transfer is important when moving on inclined surfaces, and both suspension and weight transfer are important when moving on uneven terrains. My point is that I find a 2.5d model inadequate for these situations (in particular for the last one). At least for uneven terrains, the simplest solution will be starting with a 3d model. And if the kinematics of the suspensions are to be included, 3D multibody dynamics is the way to go. However, this might not be the aim of the project, and I agree that 3 months is very little time to achieve it. I think that the scope of the project does not include having a general simulator, but a simple tool for low speed robots moving on flat floors, and to achieve it you might have to improve the tire models, rolling resistance, and maybe a simplified model of the weight transfer (for sharp turns on flat floors). However, once you add suspensions (or vertical tire deformation) you need to add vertical dynamics, and you would be dealing then with a 3d model, because the body could move vertically and lean both laterally and forward/backwards.

Regards.

Emilio Sanjurjo Maroño

Mechanical Engineering Laboratory , University of A Coruña. http://lim.ii.udc.es/index.en.html C/ Mendizábal s/n, 15403, Ferrol, Spain.

----- Mensaje original -----

De: "Borys Tymchenko" notifications@github.com Para: "MRPT/GSoC2017-discussions" GSoC2017-discussions@noreply.github.com CC: "EmilioSanjurjo" emilio.sanjurjo@udc.es, "Mention" mention@noreply.github.com Enviados: Miércoles, 31 de Mayo 2017 12:58:49 Asunto: Re: [MRPT/GSoC2017-discussions] MVSim development (Borys Tymchenko) (#2)

Hi, @EmilioSanjurjo !

It looks like right things to adhere. However, isn't weight transfer important for slow robots when moving on inclined surfaces? And what about suspension of big slow robots on uneven terrains (like automated lawn mowers)?

As to me, with 3D multibody model, it's better to start from scratch and it will definitely take more time than 3 months. Also, there is Gazebo for this purpose.

@torresmoreno , @jlblancoc , what do you think of it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

[jlblancoc]

Thanks for raising such a critical design and goal question, Emilio!

I totally agree we should not get lost regarding the project goals and scope: full 3D simulation can be done already, much better, with Gazebo. We can't, shouldn't, and don't want to compete with that giant project!

So, back to the 2D, or at most, 2D + tilted terrain, mostly even terrain, here is my idea, let me know if, given your experience, it is doable as is or needs a rethink:

• Full 3D simulation of multiple vehicles, in a general 3D world is relatively expensive. And it's the goal of other projects.
• We can limit ourselves to 2D/2.5D world models (i.e. flat terrain, or described via a "smooth" DEM).
• Collisions between vehicles and other vehicles/world objects could be left in hands of the Box2D library, so 3D shapes are disregarded. It's OK as I see it... we might tolerate some non-perfect simulations if we want a fast/efficient simulator.
• Now, what happens inside each vehicle? I envision one of two ways to go, both could be implemented during this 3 months period (via an appropriate virtual C++ interface suitable to both approaches):
  • A super simple, 2D vehicle model, without any +Z mobility (i.e. no suspension, etc.). Even in this approach, there is work to do regarding tire models, etc. (right??).
  • Drafting a 3D multibody model for each vehicle. The simulation output will be the instantaneous forces/accelerations of each vehicle, which will then be entered to the Box2D library to "move" the vehicle. In summary: "macroscopic" motion => Box2D. "Internal" motions (suspension, ...) ==> multibody dynamics. As MBD library, we can use our own one or use OpenSim or any simpler lib.

The goal is achieve O(N) complexity in simulating N vehicles, even in the case of collisions, etc. which would make the full 3D simulation more complex.

Thoughts?

[spsancti]

Hi, @all , Finally, passed all the exams for this semester, it's time to work now!

@jlblancoc , we need to implement tire models both for 2D and 3D model. The same is for rolling resistance and other viable models. It would be cool to make multibody models, but I have very little knowledge of this. Looked into our own MBD and panicked a little. Any suggested reading?

If we'd had 3d simulation, we'd needed to consider vertical twist on collisions if the vehicle is non-convex, right? Also, 2D collisions with Box2D are much simpler than hand-written 3D.

I'd started with implementing rolling resistance, tire model and weight transfer, as these ones are non-dependant on 2D/3D shape.

What do you think on tasks priority?

Now I have a long bus trip, so next time I'll be online on Sunday.

[torresmoreno]

Hi @spsancti Congratulations for your examns. Your right, indeed, Multi-Body Systems Dynamics is a really complex discipline, and implementing the full vehicle under this approach would be out of the scope of this project. So, I agree you go on implementing the tire models. Have a good journey.

[spsancti]

Hi, I'm already available. Meanwhile, I'm in Berlin. If someone is nearby, we could meet.

While travelling, I've got an interesting question: what is the method of testing for physical models used in mvsim? How do we evaluate their accuracy?

[torresmoreno]

One of the ideas of the project is to develop wrapping functions for Matlab. We could think about comparing the results of a double lane change maneuver wtr to a well-known model (might be a more realistic one) as a ground-thruth.

[jlblancoc]

Finally, passed all the exams for this semester, it's time to work now!

:clap: Great news, congrats!

Also, 2D collisions with Box2D...

I would leave collisions aside, delegate that to Box2D and live happy with such a gross estimation that gives us "good enough" results in many cases ;-)

We should clearly focus on a few core topics, since time is very limited. As mentioned earlier, I still believe that "just" developing the documentation for the current physical model, implementing rolling resistance, extending the model to a differential (one motor + two wheels), would be a significant part of what is expected in this GSoC project.

How are you doing with the LaTeX (+UML if I recall right?) documents? Is it already in your fork for us to check it out?

I'd started with implementing rolling resistance, tire model and weight transfer, as these ones are non-dependant on 2D/3D shape.

Perfect prioritization, in that exact order it's ok. Only, that I would add, as a parallel task, working on documenting everything in the LaTeX doc! It's important to have a place with all the equations and figures for us to be on the same page.

Cheers.

[spsancti]

I've started to document into Latex, but, unfortunately, only finished the friction model. It's in my fork now. I will also add car models and controllers in next few days. Also, I've generated Doxygen for it, don't know, if it is needed in the repo. There are also some diagrams present.

About the rolling resistance: How deep do we need to dig into? The most basic model involves just only one generalized coefficient and then complexity can grow infinitely. What will be the maximum speed of the vehicle in simulation? Do we consider dependency between velocity and rolling resistance coefficient? Do we always have inflated rubber tires to model dynamics, or wheels can be made of everything?

Best regards.

[jlblancoc]

About the rolling resistance: How deep do we need to dig into? The most basic model involves just only one generalized coefficient and then complexity can grow infinitely. What will be the maximum speed of the vehicle in simulation?

What are the implications? More complex models for "extreme" speeds? Anyhow, for robots, 5 to 30 km/h are typical speeds... wouldn't like to be too close to any autonomous robot faster than that ;-)

Do we consider dependency between velocity and rolling resistance coefficient?

Yes, that might, as I see it, the more complex rolling resistance model we should approach for now.

Do we always have inflated rubber tires to model dynamics, or wheels can be made of everything?

I think we could leave this as "future works" and approach it if we end other tasks, e.g. initial MATLAB bindings.

[EmilioSanjurjo]

Hi all.

Just a short comment: tire, brake and rolling resistance forces can be problematic at very low or null speed. Usually you will need to introduce a spring-damper force or some other trick to manage these situations. Just make sure that the force models you introduce work at null speed before going into super advanced models, because that will be more important for robots than the accuracy at very high speeds.

Regards.

Emilio Sanjurjo Maroño

Mechanical Engineering Laboratory , University of A Coruña. Phone: (+34)881013845 http://lim.ii.udc.es/index.en.html C/ Mendizábal s/n, 15403, Ferrol, Spain.

----- Mensaje original -----

De: "Jose Luis Blanco-Claraco" notifications@github.com Para: "MRPT/GSoC2017-discussions" GSoC2017-discussions@noreply.github.com CC: "EmilioSanjurjo" emilio.sanjurjo@udc.es, "Mention" mention@noreply.github.com Enviados: Viernes, 9 de Junio 2017 3:54:48 Asunto: Re: [MRPT/GSoC2017-discussions] MVSim development (Borys Tymchenko) (#2)

About the rolling resistance: How deep do we need to dig into? The most basic model involves just only one generalized coefficient and then complexity can grow infinitely. What will be the maximum speed of the vehicle in simulation?

What are the implications? More complex models for "extreme" speeds? Anyhow, for robots, 5 to 30 km/h are typical speeds... wouldn't like to be too close to any autonomous robot faster than that ;-)

Do we consider dependency between velocity and rolling resistance coefficient?

Yes, that might, as I see it, the more complex rolling resistance model we should approach for now.

Do we always have inflated rubber tires to model dynamics, or wheels can be made of everything?

I think we could leave this as "future works" and approach it if we end other tasks, e.g. initial MATLAB bindings.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

[spsancti]

Hi, Sorry for long silence.

If we don't consider high speeds at the moment, there are many models for rolling resistance. Linear model is also suitable. In addition, Pacejka's model already considers rolling resistance inside of it.

I've found an interesting article that introduces models for rolling resistance and traction force in case of vehicle slip: http://web.mit.edu/mobility/publications/Iagnemma_TRO_07.pdf (sections II.D and II.E) These models use less parameters and it seems to be easier to configure them.

What do you think of it?

[torresmoreno]

It could be ok. It is convinient to implement also the proposed EKF. Do you have any previous experience with Kalman Filters?

[spsancti]

I read some theory about Kalman filters, but never implemented one myself. AFAIK, MRPT has several implementations of them, couldn't we adjust one for this purpose?

[jlblancoc]

Hi @spsancti . Good you search into scientific literature... 👍 that's the way to go.

Some comments:

• On the Latex doc: Please, add a Makefile to your fork doc directory so it's easier to automate the generation of a PDF version without having to manually run pdflatex (twice...) or opening an GUI... See an example here.

I read some theory about Kalman filters, but never implemented one myself. AFAIK, MRPT has several implementations of them, couldn't we adjust one for this purpose?

You're right, MRPT has a quite generic C++ template for EKF. Take a look at this documentation page and the Doxygen docs linked therein.

However... my implementation is "quite generic", which is great for SLAM (robot map building) problems where the state vector is of a variable, growing length. In this case, it would be way simpler, so it's probably a better way if you directly code it yourself. The part of writing the Jacobian matrix, etc. would be also done if using MRPT implementation, but your code will be simpler to read and understand, IMO.

I've found an interesting article that introduces models for rolling resistance and traction force in case of vehicle slip: http://web.mit.edu/mobility/publications/Iagnemma_TRO_07.pdf (sections II.D and II.E) These models use less parameters and it seems to be easier to configure them.

Yes, it seems relatively simple, and still is realistic so... feel free of starting with that model. T-RO is a great journal and the paper has >100 citations, all of which help increasing the confidence in the soundness of the proposed simplified model.

[spsancti]

Hi, @jlblancoc . I investigated the paper and Kalman filter a bit deeper and the question raised: what for do we need this Kalman slip detection? Actually, math in MRPT Kalman is pretty sophisticated, do I need to comprehend it all, or is it better to look for some more simple implementations?

In addition, small question about models. Why is vx_veh calculated in this way? Can v_y be non-zero in case of side slip? When enabling debug there, ground truth sometimes is non-zero.

[jlblancoc]

Hi!

I investigated the paper and Kalman filter a bit deeper and the question raised: what for do we need this Kalman slip detection?

It's actually NOT required for the simulation itself. It's useful to evaluate state observers for vehicular dynamics (e.g. if we wanted to write some paper about this topic using mvsim as simulator for ground-truth comparison). But that KF would better fit, IMO, outside of mvsim; or, at least, outside of the vehicle simulation code itself. It might be an "add-on", so leave it for a later phase of the project.

Don't waste too much time trying to study it right now, go for the kinematics and dynamics first instead...

Why is vx_veh calculated in this way?

const double vx_veh = w0*R0+w_veh*m_wheels_info[WHEEL_L].y;

Local frame is: X points forwards, Y points at 90 deg to the the vehicle lefthand. So, the number m_wheels_info[WHEEL_L].y tells us where is the wheel installed over the "vehicle origin of coordinates".

The formula is an application of rigid body kinematics. An extract from our teaching material (in Spanish; for English see e.g. Wikipedia, etc. See the formula for the velocity "v_B" of point "B", given a known "v_A" and the body rotation "w":

[jlblancoc]

Can v_y be non-zero in case of side slip? When enabling debug there, ground truth sometimes is non-zero.

Correct, v_y will be !=0 in case of side slippage, when the friction force required to make it 0 is larger than the maximum frictional force according to the friction model.

[jlblancoc]

This is a kind reminder to all GSoC students and mentors

According to GSoC FAQ, students are supposed to devote 30+ hours per week to their assigned project. This amounts to 6h/day (Mon-Fri) or 4.3h/day (Mon-Sun), or any equivalent distribution given the flexibility to work on your own schedule. Clearly failing to such a commitment may be a reason to fail in the monthly evaluations, since that information was clear at the time of applying to GSoC.

It's difficult to convert hours into GitHub commits, but as a rule of dumb, there should at least a substantial daily commit during each week working day, that is, roughly 5 substantial commits per week. This is a general rule, and mentors may be flexible depending on the difficulty and nature of each project.

The first evaluation will start June 26-30.

[spsancti]

Hi I've added some docs about vehicles and controllers. Is there something else that needs to be in doc (excluding programming part)? There is also makefile present.

About tire model: will it be better to implement combined model from paper, or just add rolling resistance for our purposes?

Also, II.C assumes, that the vehicle longitudinal acceleration is negligibly small, which is generally valid for slow-moving robots. This directly affects weight transfer as effect. They tested their model only with speed up to 1.5 m/s. From my observations, real model car experiences strong weight transfer effects with speeds starting from 2 m/s. Maybe, I'd implemented their model without weight transfer first and then returned later to correct/investigate it.

When we use 2.5D, can we assume, that center of mass lies in geometrical center of the robot (just thoughts)?

[jlblancoc]

Ok, let's start without weight transfer, for consistency with the scope of mvsim.

On tire model, start with a simplest rolling resistance.

[spsancti]

Hi, Here is my short summary of papers and articles that I have been studying in June, it includes only the most important articles:

http://andresmendes.github.io/Vehicle-Dynamics-Lateral/html/DocTirePacejka.html - Pacejka tire model http://www-cdr.stanford.edu/dynamic/bywire/tires.pdf - Pacejka model short http://www.edy.es/dev/docs/pacejka-94-parameters-explained-a-comprehensive-guide/ - another one about Pacejka model https://en.wikipedia.org/wiki/Frictional_contact_mechanics - mechanics of contact patch, too sophisticated http://cats-fs.rpi.edu/~wenj/ECSE446S06/astrom_friction.pdf - not finished reading yet, many models that can be combined inside http://www.mate.tue.nl/mate/pdfs/8147.pdf - literature overview of several models with testing http://www.isir.upmc.fr/files/icra08_lucet_et_al_optimized.pdf - they design controller, but the underlying model can be used for simulation https://bitbucket.org/osrf/gazebo/src - Gazebo sources, too comlplicated but contains a lot of useful pieces http://aspe.net/publications/spring_2010/spr10ab/1010albender.pdf - model that introduces friction lag, may be considered later as advanced http://web.mit.edu/mobility/publications/Iagnemma_TRO_07.pdf - promising one, that will be implemented as starting point. Also can be used to model non-inflatable tires, tolerant to parameters' incorrect values.

[jlblancoc]

Hi @spsancti !

Thanks for the great summary of your readings. Since I know you have already participated in writing a technical paper for a conference (am I wrong?), you know what is the "related works" section of a document, right? Apart of putting this summary here, when time permits, add such a list to a "Related works" section of the Latex doc.

Just trying to synthesize what one has read, putting order in so many papers out there, is a fantastic didactic experience, and one learns a lot with it... ;-)

[spsancti]

Hi all, I added "Related works" section and will be adding docs here. Also, I almost finished simple rolling friction from Ward&Iagnemma paper.

Tomorrow I'm starting my bus trip and will be online next time on Monday.

[spsancti]

Hi, I'm here, tomorrow starting work (finally).

In my evaluation, you mentioned more frequent communications. Shall I start some kind of blog or just write reports here?

[spsancti]

Well, Ward-Iagnemma (WI) rolling resistance added to default friction model seems and feels to be working. As for me, I'd move friction model and evaluation into wheel class, because different wheels can have different friction models (e.g. front and rear wheels in WI-model). Anyway, at the moment we need to prepare some model evaluation technique, as "feeling of working" is not a good parameter. I tried to compare and plot outputs of default friction model and WI-model but none of them could be referenced as ground truth.

@torresmoreno , you mentioned some more accurate model (probably, this one?) and Matlab bindings. Do we need to be able to add our models to Matlab, or to run Matlab models in mvsim environment?

@jlblancoc , @torresmoreno , @FranciscoJManasAlvarez , any ideas on models' evaluation?

[torresmoreno]

Yes, this is a more complex model (but still not sophisticated as the multibody models), which is quite affordable to deal with. For a reference with respect to compare, it would be nice if we got access to CarSIM, or ADAMS/Car. The problem is that we haven’t licenses. Thus, we could try to use this matlab example as ground-truth. Let me discuss with @jlblancoc about the idea of coupling mvsim and matlab.

[jlblancoc]

Hi! Good to know friction is, at least, in a "feels like works" state 👍

Regarding evaluation, I think that something basic is being able to (optionally, perhaps changing some configuration file parameter) generate a plain text (csv or alike) file with the history of each vehicle, each wheel, variables: global and local velocity vectors, wheel rotating speed, traction and lateral and rolling resistance forces.... Try to do keep its implementation simple: if it's easier to generate a banch of files instead of just one, go for it. As long as each row has a timestamp, we'll be able to put the pieces together again. After that, we'll have to do the actual evaluation... perhaps just as simple as contrasting expected vs experimental curves of rolling resistance forces against some parameters? Will have to revisit this...

On matlab bindings: what I think could be considered to be a reasonable goal, before we see how complicated things become with mex's, is something like this scenario: A) being able, with a small matlab script, of starting a simulation from an xml config file. Vehicles could be manually driven via mvsim's existing keyboard teleop. Matlab methods should exist for running simulation step by step, in continuous mode (which means, creating a thread...), requesting the vehicles poses or velocities, etc. Don't worry about GUIs, just using the existing mvsim windows will work.

B) being able to provide a matlab callback function to be executed as a replacement of the current embedded PID controller, the one that takes a vehicle speed setpoint and generates motor torque. This could be a great teaching tool for control, mechatronics or robotics students

Cheers

[spsancti]

Hi, all. I wrote the simple logger which successfully integrates with QtiPlot using CSV. Find it in f-parameters-logger. Also, I found it more reproducible to use mrpt-navigation package with RViz and mvsim.

By the way, I received Matlab R2017a license for students and now can proceed with mex interfaces. (In addition, I read some docs on MEX files.)

[spsancti]

Hi, all. Tried to connect Matlab with mexCallMATLAB with PID as initiator of the call. I don't understand, how to put everything together, as matlab knows nothing about ROS and catkin knows nothing about mex. Is there a way to compile everything alltogether? I see the only way to compile something as a shared library. Probably, it is more suitable to use Matlab Engine?

[torresmoreno]

Did you try this toolbox? https://es.mathworks.com/hardware-support/robot-operating-system.html I have never used it, but maybe offers any help.

[jlblancoc]

Hi Borys,

I won't probably have time to look at your code and give a better answer until the weekend, but in the meanwhile... take a look at how mex are generated for some mrpt classes. We used macros to optionally generate mex interfaces to some regular c++ classes. See also the mex-grabber mrpt app to see example of integration.

[spsancti]

Oh, thanks. Didn't think this way. This looks like the problem solver. Will try it at weekend, as tomorrow I'm taking part here