Today’s cars are incredibly more complex than the vehicles we drove even 10 years ago, and with the move to advanced driver safety features, electric vehicles and autonomous driving there are no signs that this trend is slowing down. That said, car makers today aren’t just tapping the brains of seasoned... read more >>

]]>That said, car makers today aren’t just tapping the brains of seasoned engineers in Detroit, or Munich, or Tokyo. They are reaching deep into universities around the world to find the best student talent, because experience has shown us that these budding engineers are playing a vital role in shaping the car designs of tomorrow.

Think of it: 40 years ago many drivers had no trouble changing the oil, popping in an alternator or swapping in new spark plugs. While the archetype of the hobbyist tinkering with his muscle car in his parents’ garage is still quite alive; today it’s more likely to be a team of engineering students competing to build the prototype of a single-seat electric race car.

© Formula Student Germany, Photographer: Shidhartha, Photo Link

Through global competitions such as Formula Student, student engineers are acquiring hands-on skills that are directly transferable to real-world automotive design. Along the way, they’re also learning important lessons about teamwork, collaboration across multiple engineering disciplines, project management, budgeting, and presentation skills – lessons that they will apply professionally no matter where they end up.

In fact, Formula Student has become a recognized proving ground for young automotive engineering talent. In part that’s because of the size of the competition – approximately 550 active teams each with as many as 30 members. Formula Student is also the only competition in the world where teams start with nothing and then must conceptualize, design, build, test and race their own formula-style vehicles, and then “show” their work to a panel of judges who determine how well each team explains the logic behind the design process.

You might ask how well this model works for the car industry and what value it actually delivers. As a Formula Student team member myself (2006-2008), I can personally attest to the fact that the skills I learned serve me well here at MathWorks 10 years later. It’s also instructive to note that the “Guinness Book of World Records” holder for fastest electric car acceleration from 0-100 km/h is a Formula Student team out of ETH Zurich, Switzerland (1.513 seconds). And that the record was held before by another Formula Student team “the Greenteam” out of Suttgart, Germany. Not bad for a bunch of kids.

[Video] AMZ – World Record! 0-100kph in 1.513 seconds

As a Formula Student corporate sponsor, MathWorks provides student teams with access to our MATLAB and Simulink computational software tools. The tools help in two ways. First, they allow students to simulate their designs and accelerate prototyping, which reduces the number of physical models they must produce. This lets them try many more experiments while still getting their projects across the finish line faster. Secondly, MATLAB and Simulink are a defacto industry standard used by nearly every car maker and automotive systems supplier, which means that student teams are receiving practical, hands-on experience with the same technology they will use in their professional lives.

Car makers know this about these students. They recruit heavily from the ranks of Formula Student graduates and represent almost every recognized vehicle brand, including exotic makes such as Ferrari and McLaren. In fact, the automotive industry has hired Formula Student graduates in the 20 years since the competition was founded.

MathWorks also supports student competitors by posting an instructional video podcast series on our MATLAB and Simulink Racing Lounge site, where students (and engineers in industry likewise) can further hone their design skills. And we’re not alone. Virtually every company with ties to the automotive industry sponsors student competitions in some shape or form. It’s a virtuous circle and through MathWorks’ ongoing support of student competitions around the world I’m happy to be able to give back as much as I received.

]]>Today, I am happy to introduce Andrea Casadio, he is a junior mechanical engineer and first-time guest in this blog. Andrea is going to describe his thesis work at Politecnico di Torino in which he developed Simscape™ libraries for vehicle modeling. Thank you Andrea for providing the community with your work on... read more >>

]]>Thank you Andrea for providing the community with your work on **MATLAB Central FileExchange**.

– –

When I studied vehicle dynamics at university, I spent a lot of time modeling in Simulink^{®}. What I did in fact was creating models based on fundamental equations trying to mimic actual systems. This approach became increasingly time consuming when I used more advanced system modeling approaches. Ultimately, I spent more time building vehicle models instead of developing and optimizing simulations.

At this point, I discovered Simscape. Simscape allows me to speed-up creating models of physical systems within the Simulink environment. Simscape blocks typically provide the functionality of a system of Simulink blocks within a single block.

Anyway, describing pros and cons of Simscape is not the scope of this post. So, let’s go with the work illustration!

At the beginning of my project, I discovered that default blocks of the Simscape Driveline library allow the simulation of longitudinal behavior only. The reason is that the tire blocks provided are based on mathematical models that take into account the longitudinal forces exchanged between tire and road. As expected, MathWorks offers functionality that allows to create custom components using the Simscape language**.**

For the reason above, the first target was to develop customized tire blocks based on more involved mathematical models like Pacejka ’89 and ’96, taking into account also the combination between lateral and longitudinal forces.

Fig. 1 – Example of a customized tire block

Lateral and longitudinal forces are functions of lateral and longitudinal tire slip, which depend on translational and rotational speed of the wheel. To develop such kinds of blocks it was necessary to use Simscape language to define:

- Conserving ports to transfer speed and force information;
- Declaration of domains, variables, parameters and equations.

Conserving ports are the interface with other Simscape components, on the example shown above there are “HX” and “HY” being the conserving ports defined on the mechanical translational domain. There is also “A” which is the conserving port defined on the mechanical rotational domain.

To validate the tire model, it was necessary to apply longitudinal and lateral motion to the tire model and it was possible to obtain the plots shown in Fig.2 and Fig.3.

Fig.2 – Lateral force as a function of lateral slip at a different vertical loads – Pacejka ’89 model

Fig.2 displays the typical behavior of a tire when the longitudinal slip is zero (no braking or acceleration). The odd trend is a consequence of the Pacejka model. If you look at the block on Fig.1, there is no option to introduce a vertical load variable, this is introduced as a block parameter.

Fig.3 – Lateral force as a function of longitudinal force at a different lateral slip angles – Pacejka ’89 model

Applying different inputs to the block of Fig.1 it’s possible to obtain the graph on Fig.3, which displays how the lateral force between road and tire changes as a function of the longitudinal force for different lateral slip conditions (alpha). When the longitudinal force is zero, the lateral force is maximal. This is straightforward because tires’ grip on the corners is higher when the driver doesn’t apply brakes or throttle. The opposite condition is when the longitudinal force is maximal. In this case, the lateral force is zero. Even by common sense, you may agree that it is not a good idea to apply too much brakes or throttle on corners.

As done for tires, starting from a 3 degree of freedom (DOF) model of a vehicle, it was possible to develop a block describing vehicle body dynamics:

Fig.4 – 3 DOF Vehicle model

Here is a short description of the 3 DOF Vehicle model (Fig. 4):

- HXFR, HXFL, HXRR, HXRL are conserving ports defined on the mechanical translational domain. With these four connections it is possible to connect the vehicle body to other blocks (like tires), but only in the
. There is one port for every tire (FR means front right, RL means rear left, etc.)__longitudinal direction__ - HYFR, HYFL, HYRR, HYRL are conserving ports defined on the mechanical translational domain. With these connections it is possible to connect the vehicle body to other blocks (like tires) in
__lateral direction__ - NFR, NFL, NRR, NRL are the physical signal outputs representing the vertical loads. These ports are useful to make the block connectable with the one shown in Fig.1. In fact, the 3-DOF model doesn’t takes into account the load transfer during longitudinal or side acceleration. In this case, it’s considered being a constant value, depending on the load distribution of the vehicle on static condition without any kind of slope. ST is the physical input representing the steering angle
- PX, PT and YAW are three outputs representing the position along x, y and yaw. Yaw is the angle of rotation of the vehicle with respect to its vertical axis through the center of gravity (COG).

[Click on image to enlarge]

Fig.5 – A complete 3-DOF project – 4WD model with 3 differential

Systems like the one in Fig.5 allow to model vehicle behavior with:

- Input: steering wheel angle (ST);
- Output: coordinate of center of mass and yaw angle (PX, PY YAW).

To validate these blocks, four different configurations of a 4WD car with three differentials were defined, see Fig.6:

- All differentials opened
- Central differential locked
- Central and rear differential locked
- All differentials locked

Fig.6 – The four different configurations used to simulate the 3-DOF model

Saving on MATLAB workspace the center off mass coordinates, during the simulation, it was possible to plot the trajectory of the vehicle center of mass (see Fig.7). This plot shows, as expected, an increasing of under-steering behavior while the differentials have been locked.

Fig.7 – Vehicle trajectories at different working conditions

Modeling vehicles with the previous defined customized blocks offers, in comparison with Simulink models, a cleaner representation of the system. However, it was not straightforward to define the vehicle dynamics block based on the equations of the physical system. No worries, as Christoph pointed out, I shared the material with you on MATLAB Central FileExchange.

Another alternative is using MathWorks’ multi-body simulation tool called Simscape Multibody. Models look like the one shown on Fig.8 with its graphical representation in Fig.9.

[Click on image to enlarge]

Fig. 8 – A 6-DOF Vehicle model built with Simscape Multibody

Fig.9 – A representation of the 6-DOF vehicle model

At the end, admittedly, it is hard to give compact advice on whether to use Simscape or Simscape Multibody. In very brief, Simscape Multibody will provide a graphic representation of your model automatically as you build the model. It will also allow you to model contact – find here a detailed introduction to contact modeling. In contrast to Simscape, these additional features will require more CPU time for solving system equations.

Let me refer you to a previous article in the racing lounge focusing on vehicle modeling. Especially, the modeling approach using Simscape Multibody will thoroughly discuss the pros and cons of Simscape Multibody. And even better, all models are provided on the MATLAB Central FileExchange.

If there is one key takeaway of my work, it is this: There are many opportunities to simulate vehicle models and investigate the influence of different suspension parameters. No matter whether you are working in Simulink, Simscape or Simscape Multibody, parameters can always be modified via the MATLAB workspace.

This work was an interesting opportunity to see the great potential of MATLAB when it comes to vehicle modeling. For sure, there are a lot of future possible implementations, for example the development of further tire models to consider the load transfer or the variation of characteristics wheel angles during the suspension travel. I would love to hear your feedback about my work.

Thank you MathWorks for the opportunity to publish in the racing lounge blog!

]]>This blog post is the third one in an ongoing series introducing the MathWorks student competition team. The team is further growing and we are now 12 folks located in Boston (US), Bangalore (India), Cambridge (UK), and Munich (DE). Today’s post will introduce our new members Maitreyee, Alexa, Jose,... read more >>

]]>This blog post is the third one in an ongoing series introducing the MathWorks student competition team. The team is further growing and we are now 12 folks located in Boston (US), Bangalore (India), Cambridge (UK), and Munich (DE). Today’s post will introduce our new members Maitreyee, Alexa, Jose, and Veer. Our key mission is to equip student teams around the globe with software, training, and mentoring to tackle the same technical issues as professional engineers. Student competitions are often leading the way when it comes to new technologies, just look at the SpaceX Hyperloop, RoboCup or Formula Student Driverless competitions. Thus, we can spend our time working in trending areas such as robotics, unmanned vehicles, automated (and non-automated) driving cars.

#Drones #SignalProcessing #EmbeddedSystems #Arduino #IndianClassicalDancer #Potterhead #SareeLover

**What is your role in the student competitions team? What competitions are you focusing on?**

I work on building and executing the student competition driven by MathWorks. I work extensively with the Embedded Targets team to understand the scope of the base hardware to be incorporated in the MathWorks run student competition.

**What big project are you currently working on?**

I am presently working on exploring the Simulink support package to explore its possible scope as the base for the MathWorks run student competition.

**Which recommendation would you give students thinking about student competitions and career paths?**

Applying the learnt theoretical concepts reinforces the actual concept in our minds. And, that is the platform student competitions offer us: they help us apply all the knowledge that you have gained through the labs and courses.

**Why do you like working in education and collaborating with student teams?**

Students constantly strive to learn more things: to know why a certain thing is working, why the other thing is not. And, it is amazing when you have an opportunity to positively influence the way they perceive and learn engineering.

**Fun Facts**

- I have been learning Bharatnatyam (an Indian classical dance form) since the past 22 years and

I hold a Bachelors in Arts degree with the same specialization. - I am a big time Harry Potter fanatic.
- I can talk at length about Indian Mythology.

#MobileRobotics #BringItOn #EatSleepDrinkSimulink #50%Robotics50%Automotive #Cook

**What is your role in the student competitions team? What competitions are you focusing on?**

I work on Indian robotics and automotive competitions. At present, I am focusing on Robocon India which is a university level Robotics competition and BAJA SAE and SUPRA which are automotive competitions.

**What big project are you currently working on?**

My big project this year is to create content for Robocon and BAJA SAE. This will help students to understand the importance of usage of MATLAB and Simulink in these competitions.

**Which recommendation would you give students thinking about student competitions and career paths?**

Being a winner of the Simulink Student Challenge and MATLAB and Simulink Hardware Challenge, I understand the importance of competitions. It makes you understand the importance of time management, goal settings, learning from failures, and teamwork. My biggest piece of advice to the students is “Don’t be afraid of failures. Try new things, take risks, and learn from the failures. One day, these failures will serve you with a delicious recipe of **SUCCESS**”. Finally, choose your career which you can enjoy and cherish lifetime.

**Why do you like working in education and collaborating with student teams?**

I love to be among the students. Especially the student teams, as they are the most motivated and enthusiastic people in a college/school. I want to help the students from various competition teams to achieve their goals and prepare them for their future career. My current role at MathWorks allows me to do this.

**Fun Facts**

- I have 13k views on my YouTube video “
*Mobile robot control using Matlab/Simulink*“. - I cook delicious Biryani.
- I am a big Game of Thrones fan.

#anotherRobotGuy #theHardwareGuy #juniorRobotics

**What is your role in the student competitions team? What competitions are you focusing on?**

I support primary and secondary school robotics competitions. My focus is on the BEST and VEX competitions.

**What big project are you currently working on?**

One of my main goals is to help teachers integrate project-based learning with the use of our tools. Currently I am working on creating material to teach how to perform simple robot simulations to learn the basics of robot programming.

**Which recommendation would you give students thinking about student competitions and career paths?**

Get involved in as many competitions as you can and do it early in your education. Competitions will help you meet new people and learn the engineering workflows and how to collaborate with others. Hands-on competitions are also a great way to develop the problem-solving skills required in the industry.

**Why do you like working in education and collaborating with student teams?**

Working with students is great because the environment is by far the most resourceful and fast-paced among scientific and engineering fields. I really enjoy teaching so this role gives me a great opportunity to share knowledge, in most cases, we also learn a lot from the student teams.

**Fun Facts:**

- I am a guitar player.
- I am total car guy and Volkswagen fan.
- I have two turtles named cuff and link.

#BookNerd, #NewEnglander #HorrorMovieFan

**What is your role in the student competitions team? What competitions are you focusing on?**

I work on a few other academic programs, including the Book Program and MATLAB Student Ambassadors Program. With the Book Program, I support authors and publishers in developing books with MATLAB and Simulink content. With the MATLAB Student Ambassadors Program, I support the Student Ambassadors in coordinating fun on-campus events and gathering together their schools’ MATLAB communities.

**What big project are you currently working on?**

We promote books with MATLAB and Simulink content on our website here. I work on finding and obtaining access to new books in a variety of industries, and promoting them online to share these resources with our MATLAB community.

**Which recommendation would you give students thinking about student competitions and career paths?**

Take advantage of all the learning resources and programs we have to offer! Try new things whenever you can and think about what skills you most enjoy, and doing those things should help you find a career path that will make you happy.

**Why do you like working in education and collaborating with student teams?**

I enjoy helping people learn and getting the most out of their education. If I can make a student or educator’s life even a little easier I feel like I’ve succeeded.

**Fun Facts:**

- I’ve folded over a thousand paper cranes.
- I once rode a camel in Morocco.
- I like to bake – especially when what I’m baking involves chocolate.

That’s it for now, I will make sure to welcome newcomers as they arrive. Please let me know in case you want me to put you in contact with someone in the team.

Cheers Christoph

]]>In the first part of this post, I introduced the hydraulic decoupled suspension concept designed by Timothy Novotny and Alex Hönger from AMZ Racing. In this second part learn about their design process and how they verified and tested the hydraulic decoupled suspension. Dimensioning A question about the weight target was asked during... read more >>

]]>In this second part learn about their design process and how they verified and tested the hydraulic decoupled suspension.

A question about the weight target was asked during their presentation. Alex’s answer was to be expected: “*Our goal was to have a lighter system than the previous!*”. Admittedly, it is a bit tricky to do a net comparison of weight because the new system is very different. By assessing conservatively, they ended up with 1kg heavier than last year’s concept where most of the added weight comes from shielding the hydraulic pipes. These had to be made from PTFE with braided steel shielding to comply with the rules.

The hydraulic decoupled suspension is a nice opportunity to accumulate heavy items such as the central unit low and close to the center of gravity (COG). The team decided on locating the central unit just behind the driver where it is easy to access and helps to keep the package tight.

While researching for hydraulic components, especially cylinders, Timothy and Alex recognized that it is impossible to get exactly what they needed, mainly because hydraulic components are typically not optimized for lightweight design. Thus, they were forced into designing their own hydraulic cylinders.

The team already accepted some risk when deciding for the concept, but now the risk increased. What if they could not manufacture the system? Or even more fundamentally, what if their design would not fulfill its tasks? Alex was asked whether they were considering a back-up system. His answer was “*Yes, but we didn’t build one*”. At this point in the process, the AMZ Racing team made a bold decision and trusted their suspension gurus who were convinced that they could get it done.

At the end, Alex and Timothy designed about 60 custom parts and manufactured them with the help of partners. The major and most complex assemblies are certainly the three cylinder units.

As depicted in the main concept (see part 1 with animated GIF), many parallel cylinders needed to be integrated. For example, the pitch cylinder consists of 4 chambers, all packed tightly together. The heave cylinder consists of 8 chambers – 4 of them open to the atmosphere. By arranging in one line, the force flow could be improved a lot. During construction, it was all about shortening the axial length while maintaining enough stroke for the cylinders. Alex puts it this way: *“By choosing an extreme motion ratio you can shorten the cylinder length quite significantly by just decreasing the stroke. But this increases the forces, […]. So, it’s a trade between stroke and forces. It was literally a fight for every tenth of a millimeter of axial length.”* Furthermore, a major concern was whether they would be able to bleed the system and get all the air out. Hence, in the design stage, every chamber got a bleed access at the highest position over ground.

At one point, the entire project was at stake. During assembly and early sub-component tests, AMZ found that sealing a complex 120bar system is challenging and that the surface finish of cylinders is a key criterion to achieve that. Alex and Timo faced severe problems with the finish of the inner sealing surfaces made of Ni-coated aluminum (see photo). Main parts had blisters and even the replacement ones were not safe to use. This would lead to breaking seals in a short time. By literally getting their hands dirty and improving the surface finish manually, they got the problems under control. In my mind, this is a perfect example of difficulties that I mentioned in the introduction. These appear in the best-planned projects and are impossible to foresee. AMZ resolved them with dedication and massive manual effort. And to be very honest, there was no other option because accepting failure would mean: ending the car project and making efforts of the entire team AMZ obsolete, at least for the 2018 season. Which, I guess, was never an option.

Find here an illustration of the entire system mounted in the 2017 season racecar called *pilatus*

I hope you agree that looking at this illustration pursuing to understand the way the hydraulic system works is causing a big headache. Alex admitted that while designing *“most of the resources were spent on the cylinders and attaching them. Little time was spent in the connection of the cylinders.”*. But one way or the other, all cylinders must be connected to the dampers near the wheels. This means having hydraulic lines through the already tightly packaged chassis. Alex’s ideal world would also include a pressure sensor as well as an oil adjustment cylinder. Again, many hours and probably a few confrontational discussions later, AMZ came up with an approach of minimized parts size while keeping them easy to manufacture.

Let’s have a look at the system in action. Enjoy this video as it will show most of the moving parts as well as vehicle parameters helping us to understand what is actually happening. The run was made during a postseason test on a rather bumpy and curvy track. Alex noted that the car was driven by an unexperienced driver – Him.

Admittedly, I replayed the video many times and enjoyed observing the gauges for speed, torque, steering-angle, as well as the g-g plot and position on track while trying to imagine the suspension modes. Great job Alex in combining the essence in one video and sharing it with us!

To illustrate the benefits on the track, Alex also provided data. The two graphs below compare *gotthard* (2016’s car) and p*ilatus* (current). They show the load difference between the two wheel-pairs on the diagonal versus the lateral acceleration of the car.

For perfectly unsprung warp, these cross-wheel loads would cancel each other out. However, setting a certain roll balance connects roll and warp which results in nonzero cross-wheel loads: the higher the lateral acceleration, the higher the deviation should be.

The thin band of data points in the pilatus graph nicely illustrates that setting the roll balance works like a charm. This is finally confirmation that the concept of hydraulic fully-decoupled suspension can be used in racecars. The range of y-values results from friction of the hydraulic components and particularly the tires. In comparison, *gotthard’s* plot reveals that warp is not unsprung. The y-range of data points is much higher resulting from, e.g., bumps in the track. This transfers many more unnecessary loads to the chassis.

Apart from the proof of concept that brings a smile to the engineer’s face, let’s not forget about a much more important factor. The car’s behavior is much more balanced helping the driver to perform at the limit and drive faster.

I think, Timothy and Alex grew to engineering adults during the project. They were given the opportunity to execute a brilliant idea and they coped with the challenges that nobody could imagine at first sight. To me, they are role models for students entering student competitions.

AMZ Racing and I are looking forward to your questions and a lively discussion in the comments section of this article!

All images on that page © AMZ.

]]>

© kreutzweise.de Great ideas don’t always stand the test of time. It may be due to some drawbacks that knock out the great advantage, or it simply is too expensive or difficult to implement. The following article will share a contradicting example. Enjoy this engineering success story of originality and rock-solid engineering... read more >>

]]>Great ideas don’t always stand the test of time. It may be due to some drawbacks that knock out the great advantage, or it simply is too expensive or difficult to implement. The following article will share a contradicting example. Enjoy this engineering success story of originality and rock-solid engineering skills.

Timothy Novotny and Alex Hönger, from AMZ Racing of ETH Zurich, presented their concept of a hydraulic decoupled suspension at the Formula Student Germany Workshop in October 2017 [video link]. AMZ Racing is one of the teams where model-based design is part of their DNA for racecar development. They use MathWorks products for a multitude of applications such as lap-time simulation, control design, optimize trajectory planning for their driverless car and many more.

For that specific project, the team accepted significant risk by allowing Timothy and Alex to pursue their bold idea from early stage concept until functioning in a winning racecar. The result is a proof what bright minds in conjunction with a powerful team and its partners can achieve.

The primary goals of a racecar suspension can be summed up briefly. It should maximize overall grip while minimizing wheel load variations. Furthermore, it should reliably exhibit predictable and driver-friendly behavior.

Movements of an acting suspension can be described by 4 modes: Pitch, Heave, Roll and Warp. Let’s use our imagination and assume a street bump just ahead of the front left wheel. The reaction force on the suspension will try to lift the whole chassis (heave), lift the front axle (pitch), lift both left wheels (roll), and twist the front axle relative to the rear axle (warp) – all at the same time.

© AMZ

**Pitch**is induced mainly through braking and acceleration. Ideally, pitch stiffness would show an approximately linear force-displacement behavior.**Heave**results primarily from aerodynamics loads. The race engineer would want it to act progressively, i.e. increasing spring stiffness with increasing load.**Roll**typically happens while cornering. For the sake of balancing, rolling stiffness should be linear and happen symmetrically between left and right.**Warp**results from maneuvering and track irregularities (see illustration below). Ideally, this mode should be unsprung. This means that movements should be allowed to happen freely, without a spring or damper balancing the deformation. Of course, the tires are not rigid bodies .

The key idea that Timothy and Alex had was to fully decouple modes. They imagined a system with 4 degrees of freedom, one for each mode, where stiffness and damping can be adjusted independently. This would simplify set-up and lower the single wheel stiffness by at least 25%. The team also could better leverage the potential of their already implemented magneto rheological fluid (MRF) dampers and integrate active suspension components.

Let’s revisit their thought process for an early stage concept. A main drawback of common suspension concepts is that decoupling of heave from pitch and roll from warp cannot be done without adding a connection between front and rear axle. Adding further rods was dismissed because of its potential added weight, the negative impact on the package, and the large number of attachment points it would require.

Timothy and Alex thought about various hybrid mechanical-hydraulic systems before coming up with the idea of a fully hydraulic suspension. See the illustration below and follow this** link for an animated GIF**.

© AMZ

Each wheel would have its own hydraulic system (see colors in the figure above). All elements that share a color would be connected to each other. Consequently, there are no connections between elements of different colors. Certainly, there would be a central unit comprised of four elements: one for each mode. Admittedly, in the figure above, there is a three-part central unit. This results from the combination of warp and roll elements through a lever arm. In an earlier concept, the central unit had different elements for roll and warp as can be seen below.

© AMZ

The warp element is a bit special. There is no spring because warp should be unsprung.

There are many added benefits of the lever arm configuration. The system is presumably lighter and allows simpler tuning of the roll balance by adjusting the length of the left and right lever arms. Roll balance can be described as a connection between roll and warp. Roll movements actuate warp and thus increase tire load on the wheels of one diagonal.

I hope you click back to the racing lounge for the second part of this story. You will read about detailed design, manufacturing and testing … and see some awesome videos of the system in action.

]]>The Racing Lounge is back from Christmas break. I wish you all a succesful and healthy 2018! In today’s post, Sebastian Castro discusses his experiences with a robotics workshop he helped deliver at the RoboCup Asia-Pacific (RCAP) event in Bangkok, Thailand. As a reminder, MathWorks is a global sponsor of RoboCup which comes with many benefits to student... read more >>

]]>In today’s post, Sebastian Castro discusses his experiences with a robotics workshop he helped deliver at the RoboCup Asia-Pacific (RCAP) event in Bangkok, Thailand.

As a reminder, MathWorks is a global sponsor of RoboCup which comes with many benefits to student teams. At RCAP, we had a booth with information, giveaways, software demonstrations, and more. We were even joined by our distributors in Southeast Asia, TechSource. Next time you’re at a RoboCup event, please stop by and say “hi”.

*MathWorks and TechSource at our booth*

One of the biggest challenges in RoboCup is the jump from the Junior (pre-university) leagues to the Major (university-level) leagues. Typically, there is a significant learning curve that stops even the most successful Junior teams from continuing in RoboCup once they move from high school to university.

Many RoboCup organizers are aware of this issue, which had led them to create intermediate challenges targeted at overcoming this learning curve. Unlike the Major league competitions, which are primarily research platforms for students pursuing advanced degrees, these challenges are more suited for educating undergraduate students. Some examples are the RoboCupRescue Rapidly Manufactured Robot and the RoboCup Asia-Pacific CoSpace challenges.

What made RCAP extra special for us was being invited by Dr. Jeffrey Tan to help with another challenge of this type. Dr. Tan has been an organizer with the RoboCup@Home league for over 4 years, as well as an advisor for the KameRider team. We decided to deliver a joint workshop for his RoboCup@Home Education league. This was a great opportunity for us because it allowed us to introduce MATLAB into various aspects of robot design and programming, and served as a good benchmark of our tools in a real, world-class competition.

There were 4 teams participating:

**Tamagawa Science Club**— Tamagawa Academy, Japan — high school**Nalanda**— Genesis Global School, India — high school**KameRider EDU**— Nankai University, China/Universiti Teknology Malaysia — undergraduate**Skuba JR**— Kasetsart University, Thailand — undergraduate

*RoboCup@Home Education Crew — Courtesy of Dr. Kanjanapan Sukvichai (Skuba JR advisor)*

For the first 2 days, we came up with an ambitious curriculum of topics that got the students up and running with a TurtleBot2 from scratch — including an RGB + depth sensor and a robot arm.

All we requested in advance was to bring a laptop with Ubuntu 14.04. We then installed the Robot Operating System (ROS) and MATLAB with a complimentary license from our Web site.

The goal was to develop the pieces of a typical RoboCup@Home algorithm. If the robot has a map of its environment and receives a spoken command — for example, “*bring me the water bottle from the kitchen*” — the diagram below is an example of the components needed to complete that task.

Speech recognition was done with CMU PocketSphinx, while speech input and synthesis was done with the audio_common stack. In the workshop, we showed how to detect speech, look for key words in a dictionary, and take actions based on those key words. This was all done outside of MATLAB.

Several students asked about MATLAB’s capabilities for speech recognition. Right now, there are two ways to get this working:

- Use the ROS tools above to publish the detected text on a ROS topic and subscribe to it in MATLAB.
- Call a user-defined Python speech module from MATLAB.

Once the text is in MATLAB, you can take advantage of its capabilities for characters and strings, or even the new Text Analytics Toolbox.

I have personally got approach #2 working with this Python SpeechRecognition package — in particular, with Google Cloud Speech and CMU PocketSphinx. The image below shows a simple example I ran which used Text Analytics Toolbox to cluster my speech into two categories — food and drink. There are words like “going”, “have”, and “some” which give us no extra information. Luckily, the toolbox has preprocessing capabilities to address such issues.

To perform mapping and navigation tasks, we took the following workflow

- Generate a map of the environment using the existing TurtleBot gmapping example and driving the robot around.
- In the example above, the latest map is published on a ROS topic (/map). So, we can read the map into MATLAB as an occupancy grid and save it to a file.
- Once the map is in MATLAB, we can sample a probabilistic roadmap (PRM) and use it to find a path between two points.
- Then, we can program a robot to follow this path with the Pure Pursuit algorithm.

Below you can see an example map and path I generated near my office. Assuming the map is static, steps 3 and 4 can be repeated for different start and goal points as needed.

For this task, we operated exclusively in the MATLAB world. We received many comments about prototyping with images being easier than with OpenCV, mostly because more challenging languages (Python or C++) were required for the latter.

Our vision and control workflow was:

- Using the Color Thresholder app to define thresholds for tracking an object of interest
- Performing blob analysis to find the object position
- Estimating the distance object using the depth image at the detected object position
- Moving the robot depending on the object position and depth. We started with simple on-off controllers with deadband on both linear and angular velocity.

At this point, students had reference MATLAB code for a closed-loop vision-based controller with ROS. Over the next few days, they were encouraged to modify this code to make their robots track objects more robustly. Let’s remember that most of the students had never been exposed to MATLAB before!

The robots were fitted with TurtleBot arms. There were two sides to getting these arms working: hardware and software.

On the hardware side, we pointed students to the ROBOTIS Dynamixel servo ROS tutorials. The goal here was to make sure there was a ROS interface to joint position controllers for each of the motors in the robot arm. This would allow us to control the arms with controllers in MATLAB.

On the software side, the steps were:

- Import the robot arm description (URDF) file into MATLAB as a rigid body tree representation
- Become familiar with the Inverse Kinematics (IK) functionality in the Robotics System Toolbox
- Follow a path by using IK at several points — first in simulation and then on the real robot arm

The figure below shows a path that linearly interpolates between points. However, smoother trajectories are also possible with a little more math, or with tools like the Curve Fitting Toolbox.

The workshop days were meant to raise awareness of software tools needed to succeed in the competition. With a stack of ROS tutorials, example MATLAB files, and other useful links, the students were now tasked with taking our reference applications and using them to compete in the same challenges as the major leagues.

These challenges were as follows. Credit to Dr. Tan’s KameRider team for the sample YouTube videos.

**Speech and Person Recognition:**Demonstrating basic speech and vision functionality. An example would be asking the robot “how many people are in front of you?” and getting a correct answer. [Person Video] [ Speech Video]**Help-me-carry:**Following a person and assisting them by carrying an object. [Help-me-carry Video]**Restaurant:**Identifying a person ready to place an order, correctly listening to the order, and retrieving the object that has been ordered [Restaurant Video] [Manipulation Video]**Finals:**Teams can choose freely what to demonstrate, and are evaluated on criteria such as novelty, scientific contribution, presentation, and performance

During this time, students were spending hours digesting workshop material, testing their code, and slowly building up algorithms to clear the challenges.

*Tamagawa Science Club robot during the competition — Courtesy of Dr. Jeffrey Tan*

Some highlights:

- Teams experienced firsthand how to take pieces of code that performed different tasks and integrate them into one working system.
- All teams had complete computer vision and control algorithms with MATLAB, but not all teams had functioning speech detection/synthesis and manipulator control. They found the MATLAB code easier to set up and modify than some of the other ROS based packages, which required knowledge of Python, C++, and/or the Catkin build system to use and modify.
- The two high school teams successfully generated a map of the environment and implemented a navigation algorithm.
- The Nalanda team was able to add obstacle avoidance to their robot using the Vector Field Histogram functionality in Robotics System Toolbox.
- A handful of teams were able to tune some of the pretrained cascade object detector and people detector examples for their person recognition and final challenges.

*KameRider EDU during the Person Recognition challenge — Courtesy of Dr. Jeffrey Tan*

This event was a lot of fun, and as a bonus I enjoyed escaping the cold Boston winter for a few weeks. It was satisfying to see how much the students were able to achieve, and how our conversations evolved, in such a short time frame.

- At the beginning, it was mostly questions about installation, error messages, basic MATLAB and ROS questions, and “how am I going to get all of this done?”.
- Near the end, students had a pretty good understanding of basic ROS constructs (topics, messages, launch files, Catkin, etc.), general programming tools (conditional statements, loops, functions, breakpoints, etc.) and — most importantly — were already asking “what’s next?”

*Workshop in action — Courtesy of Team Nalanda*

The general consensus was that both MATLAB and ROS were needed to make this workshop happen. Implementing and testing algorithms was made accessible by MATLAB, whereas installation of existing ROS packages facilitated some of the necessary low-level sensing and actuation, as well as mapping, capabilities.

- Many ROS packages were easy to set up and could deliver powerful results right away. However, understanding the underlying code and build system to modify or extend these packages was nontrivial for beginners. This is likely because ROS is designed for users comfortable with a rigorous software development process.
- On the other hand, MATLAB needed a single installation at the beginning, required no recompilation, and the sample code (both our workshop files and documentation examples) was determined easy to follow, debug, and modify.

Heramb Modugula (Team Nalanda) remarked that “plenty of time was available to tinker with the robot and example code, and eventually, coding on our own”. His coach and father, Srikant Modugula, highlighted integration of software component as the most critical task. “While MATLAB provides a powerful framework to do robotic vision, motion, and arm related tasks, we look forward to an easier way to connect it with ROS enabled TurtleBot and seamlessly compile/run multiple programs.”

*Computer vision and manipulation at the workshop — Courtesy of Dr. Jeffrey Tan*

To summarize, MATLAB and its associated toolboxes are a complete design tool. This includes a programming language, an interactive desktop environment (IDE), graphical programming environments like Simulink and Stateflow, apps to help with algorithm design and tuning, and standalone code generation tools.

Our recommended approach is to use MATLAB and Simulink for prototyping algorithms that may be a subset of the entire system, and then deploying these algorithms as standalone ROS nodes using automatic code generation. This way, the robot does not rely on the MATLAB environment (and its associated overhead) at competition time. For more information, please refer to our Getting Started with MATLAB, Simulink, and ROS blog post or reach out to us.

*Find the MathWorks logos!*

Our goal is that challenges like these will lower the entry barrier for new teams from around the world to join the RoboCup major leagues and perform competitively in their first year. This will create opportunities for newcomers to become comfortable with robot programming and eventually transition to being “true” major league teams — that is, bringing state-of-the-art algorithms to RoboCup and pushing the boundaries of robotics research worldwide.

For this reason, we will work towards offering this workshop at future events, as well as open-sourcing our materials and posting them online. If you are interested in using this material to learn or teach, or have any thoughts to share, please leave us a comment. We hope to see more of you sign up for future RoboCup@Home Education challenges. Until next time!

]]>Many students I know take issue with Plato’s famous quote: “Students are lazy, disengaged and have bad manners” (The Republic VIII, 562b-563e). Stepping back from the ‘bad manners’ accusation, engaging and effectively teaching bored students can be challenging and the reasons behind haven’t become clear to me for quite some... read more >>

]]>Central to the concept of project-based learning is putting **students** in an **active role**, **encouraging** them **to explore a realistic problem** in an area of interest to them and **without a predefined solution**. This is effective when teaching STEM (science, technology, engineering and math) subjects as it brings theory to life and closely mirrors the problem solving required in science, engineering and math careers. Project-based learning also teaches additional skills such as **team work and critical thinking**, vital for any future career.

Project-based learning environments have **five key features**, addressed below.

All problems start with questions. From where does one draw inspiration for those questions? As you read through your social networks (as you are doing now): what makes you stop and read posts but scroll past others? On the one hand, it depends very much on us as individuals, our social environment and our interests. On the other hand there are topics that have broad appeal, such as **climate change or the soccer world championship**. Mapping that back to our key statement, the logic seems straightforward: identify a “driving question” and hide the key learnings behind it.

I spoke in an earlier post about Formula Student about the importance of student competitions to improve the skill set. This competition also provides an excellent example of how posing a question drives learning. Formula Student is quite complex and as such raises multiple questions; the overarching question set by the organizers is ‘how do teams design and develop a single seat race car, good enough to beat other teams?’ But for students to want to in participate in the year-long event, the question posed to themselves is ‘How do I get the job I want, and differentiate myself from other candidates?’

Another great set of examples comes from LEGO. They are developing fantastic ecosystems around the core education ideas in a department called LEGO education. For example, their content is synchronized with the primary and high school curriculum in many countries such as the UK. They are excellent at **story telling** to create environments for learners of all ages. There is material for learning math in first grade called “MoreToMath” as well as concepts to teach programming and control design “**LEGO Mindstorms**” and many more for the wide range in between.

In high school math, one of the lessons I faced was understanding the concept of imaginary numbers, stating that multiplying a number with itself leads to a negative number: i * i = – 1. It requires abstract thinking and is certainly not straightforward. When I asked our teacher “Why do we need that?” he was unable to answer. Years later, during my mechanical engineering studies, I was exposed again to imaginary numbers in a course covering electric motors.

Had my high school teacher started his lesson with the application of imaginary numbers as it relates to motors, and then progressed to the theory behind them, I would have been much more interested and inclined to learn. When I am showing students software and hardware demos at competition events I usually start on a high level. As soon as I get them “on board” and they recognize their problem, no matter whether it relates to a robot or race car, it is pretty easy to get them involved. Mostly they see the value and start to ask questions about the underlying fundamentals on their own.

Another example is the game commonly known as **Wall Street game**. Students are given an imaginary budget that they can invest in stocks to (hopefully) increase their pot of money. Is there any greater motivation than competing against classmates? Students learn about the stock market, risk and probability. This is also sometimes called the **flipped classroom** – students are engaged through something fun and exciting, before being taught the theory behind it. Tasks should be age appropriate – interesting and exciting to the respective age group.

You may have heard that sharing ideas, exchanging feedback, iterating in a group will lead to better solutions. **Teamwork sounds great, but it’s not an easy task** to get everyone to agree if it does not tie to their objective. A big group with no one taking responsibility for the result might not lead to a great outcome. However, we can’t dispute that complex problems can only be handled in a group and the greater the team collaboration the better the outcome.

Project-based learning is an **ideal approach to teach collaboration and teamwork**: students learn by doing. Of course, at the beginning it often seems harder to work as part of a team, to fight for the best ideas, and to find common ground or to execute things with distributed workforce. The list of potential problems can be extended easily and often seems endless. Subverting these fears and objections is one of the great outcomes that project-based learning can provide. Consider the impact of receiving feedback from someone you admire, whose judgement you trust: this can be a great **reward and a strong motivator** that can only be achieved when working in an open and collaborative way.

Formula Student is a great example that highlights the importance of the project-based learning message. Simply the scale of the project could never be handled without effective collaboration and teams get feedback from people in companies they’d like to work for.

It’s a common problem for teachers: how do you enthuse the disengaged while also challenging and fostering talented individuals? **Project-based learning meets the needs of different learning styles** but also gives students the opportunity to push themselves beyond that demanded by the curriculum. Some might complete the project at its most basic level, but others, when faced with a challenge that interests them, will push themselves above and beyond, thus evolving their learning further.

At nation-wide finals, selected participants of the German science competition Jugend forscht display their projects. Jugend forscht allows young researchers between the age of 15 and 21 years to compete in subject areas such as mathematics / computer sciences, physics or technics. Some of their submissions are fantastic examples of what teenagers are able to achieve when they’re inspired and challenged. As an example, the winning team in the computer science branch used statistics and numerical models to compute light scatter creating realistic images of diamonds. The contest also featured robots moving on one leg and some able to solve Sudoku grids. What these projects all have in common: they go far beyond what is taught in school and the kids participating are passionate about the work.

Source: Bundeswettbewerb Jugend forscht 2015 bei BASF , by BASF (CC BY-NC-ND 2.0)

What is the motivator driving you to succeed? Is it the recognition from others or a sense of personal achievement? For some it might be **money, a valuable prize or a job opportunity**. For many, it’s having something tangible to show at the end of the class or day of work.

Whatever the personal motivator is, this reward encourages people to push themselves. Consider the primary school students tasked with programming a robot and the sense of achievement at completing the task as part of a team. Compare that with the university teams competing a Formula Student; at the end of the year-long project they have a single seat race car to show for their efforts, strong job prospects and (hopefully) a prize from the event itself. **Having something tangible to show for their efforts drives people and thus their learning**.

Teaching methodologies need to **support different learning approaches** as well as **inspiring and engaging students**. Project-based learning, incorporating the five columns above, is an effective way to achieve this. By getting **students working hands-on**, they **explore real-world problems and bring theory to life**. Key to the success are projects that are fun and inspiring for students – they can work on applications ranging from robotics to signal processing to control systems. In doing so, they’re also learning approaches and skills that are relevant to their future careers. I welcome your thoughts on project-based learning, either from your own experiences, or questions you might have.

Reference:

[1] The textbook The Cambridge Handbook of the Learning Sciences includes a nice chapter authored by J.S. Krajcik and P.S. Blumenfeld which discusses the concept.

Introduction This blog post intends to provide best practices for choosing solvers in Simulink and Simscape. Gratitude goes to Tom Egel and Erin McGarrity whose materials are the foundation for anything written below. This article is certainly not aiming to replace the rock-solid documentation about solver choice, it is complementary and... read more >>

]]>This blog post intends to provide best practices for choosing solvers in Simulink and Simscape. Gratitude goes to Tom Egel and Erin McGarrity whose materials are the foundation for anything written below. This article is certainly not aiming to replace the rock-solid documentation about solver choice, it is complementary and written for folks who:

- want to speed up simulations and increase accuracy,
- need a better understanding of the numerics involved.

This article will firstly talk about solver classification and naming, and secondly mention practical aspects about finding the optimal solver for your application and working around common mistakes. Simscape will not (yet) be covered specifically. Feel encouraged to leave a note in the comments section at the bottom if you are particularly interested in troubleshooting Simscape models.

This introduction may trigger two kinds of reactions:

*“***I want to know more!**”-> Find here a

**Solver Workshop on FileExchange**which is a hands-on deep dive into solver know-how including example models, slides and exercises.*“***I don’t want to invest time into solver choice!**”

-> I suggest having a look into**auto solver**, a**feature**that was added in release 2015a. It will choose an appropriate solver for your model automatically.

This example of a **Foucault pendulum **(Link -> *foucaultPendulum.slx*) illustrates why solver choice is key! Depending on the solver choice ode45 (default) or ode23t, results of the pendulum displacements will be entirely different. As can be seen in the plots, ode23t leads to more meaningful results since the displacements should be symmetric. Sometimes, errors won’t be as obvious. My PhD supervisor typically said when discussing modeling strategies “Christoph, all models are wrong, but some of them are useful.” In the following, let’s try to make sure that simulation results will be useful.

Open and run the model *“foucaultPendulum.slx”* in the solver workshop on FileExchange to experience the illustrated solver behavior. Before talking about model stiffness which lead to the significant result deviations in the example above, let’s do the groundwork first and see what Simulink / Simscape solvers there are and how they can be classified.

**Names and their Meaning**

The most important info is carried by the solver names themselves. A single digit number represents a fixed-step solver, the number itself gives info about the order. Information on the integration scheme can also be obtained from the name. Solvers using an implicit scheme always come with an amended letter, explicit solvers only have the number. The amendment letters are abbreviations: “t” trapezoidal, “tb” trapezoidal-backward, “s” stiff and “x” extrapolation. If there is no amendment, that’s an explicit solver.

**Classification**

MathWorks solvers can be classified into 4 categories:

*Step Size – Order – State Updates – Integration Scheme.*

*Step Size*

Fixed-step solvers are typically used for to meet accuracy requirements and are used when models will be deployed onto hardware such as microcontrollers (keyword: code generation). Variable step solvers automatically change the time step to meet requirements. They are typically used for plant model development. A variable-step solver might shorten the simulation time of your model significantly.

This model shows how a variable-step solver can shorten simulation time for a multi-rate discrete model. The model generates outputs at two different rates: every 0.5 s and every 0.75 s. To capture both outputs, the fixed-step solver must take a time step every 0.25 s (the *fundamental sample time* for the model).

*Order*

As mentioned before, the numbers used in the solver name specify the solver order. Choice of order has an impact on accuracy. Most often, a high-order solver is more efficient than a low-order solver. Variable-order solvers use multiple orders to solve the system of equations. For example, the implicit, variable-step ode15s solver uses first-order through fifth-order equations while the explicit, variable-step ode113 solver uses first-order through thirteenth-order. Solver’s **step size** and **integration order **have a huge impact on accuracy. In my mind, the simplest way of explaining is the following:

- Smaller step size and higher solver order both increase accuracy
- More accuracy is slower (at least for a fixed-step solver)

*State Updates: Discrete vs. Continuous*

Discrete and continuous solvers rely on the model blocks to compute the values of any discrete states. Blocks that define discrete states are responsible for computing the values of those states at each time step. However, unlike discrete solvers, continuous solvers use numerical integration to compute the continuous states that the blocks define.

If your model has no continuous states, then Simulink switches to either the fixed-step discrete solver or the variable-step discrete solver. If your model has only continuous states or a mix of continuous and discrete states, choose a continuous solver from the remaining solver choices based on the dynamics of your model. Otherwise, an error occurs.

*Integration Scheme: Explicit vs. Implicit*

Explicit solvers use past information in the equations to compute next step. This is computationally simple but unstable as the system equations won’t be solved completely at any time. Instability is not necessary a problem because everything will be fine if the approximated solution is still within your desired margin of error. Implicit Solvers compute next steps self-consistently which is more computational work per step.

While you can apply an implicit or explicit continuous solver to solve all these systems, implicit solvers are designed specifically for solving stiff problems. Explicit solvers solve non-stiff problems. An ordinary differential equation problem is said to be stiff if the desired solution varies slowly, but there are closer solutions that vary rapidly. In short, one could say: a stiff system has both slowly and quickly varying continuous dynamics. The numerical method must then take small time steps to solve the system. Stiffness is an efficiency issue. The more stiff a system, the longer it takes to for the explicit solver to perform a computation. For example, most of the physical models built using the Simscape product family end up being stiff systems, in which case you would want to make sure you choose between stiff solvers.

**Solver Choice**

When you build and simulate a model, you can choose either type of solver based on the dynamics of the model. A model that contains several switches, like an inverter power system, needs a fixed-step solver. A variable-step solver is better suited for purely continuous models, like the dynamics of a mass spring damper system.

When you deploy a model as generated code, you can use only a fixed-step solver. If you selected a variable-step solver during simulation, use it to calculate the step size required for the fixed-step solver that you need at deployment.

**Zero-Crossings**

Note: This is relevant if you have chosen a variable step solver only.

A variable-step solver dynamically adjusts the time step size, causing it to increase when a variable is changing slowly and to decrease when the variable changes rapidly. Thus, the solver takes many small steps near a discontinuity, e.g. a zero-crossing. Zero crossing events may be sign changes or hard stops. Overall, this behavior improves accuracy but can lead to excessive simulation times.

Knowing that zero-crossing may slow your model down is already a major part of the solution. Find here a list of possible remedies:

- Adjust the zero-crossing options

(Configuration parameters -> Additional options)- Increase number of consecutive zero crossings
- Switch to the adaptive algorithm
- Relax signal threshold
- Disable detection for specific blocks, see documentation

- Modify the model and reduce constraints

This is not just a setting, let me refer you to the solver workshop (FEX) for a hands-on example.

**Algebraic Loops**

An algebraic loop generally occurs when an input port with direct feedthrough is driven by the output of the same block, either directly, or by a feedback path through other blocks with direct feedthrough. Thus, the solver is forced to use iterative methods which is slow (!).

The best remedy is to avoid algebraic loops if possible, find a chapter helping you in the documentation or have a look at the solver workshop (FEX) introduced before.

This article is by no means complete nor is it the only publication about this topic. Same as for models that should be useful, I hope this text helps you in your daily work with Simulink. Feel encouraged to comment and suggest improvements or clarification.

Cheers Christoph

]]>

Ka.Race.Ing-Team at Karlsruhe Institute of Technology volunteered to share in depth and hands-on their approach around vehicle controls and torque vectoring in particular. They are winners of the Simulink Student Challenge 2016. And to top it all off, Julian our guest blogger today, added two of their models on the MATLAB... read more >>

]]>– – –

In recent years of electric of Formula Student, control systems have gained importance. The impact of well-tuned torque vectoring and traction control systems is comparable to a weight reduction of 10kg. However, it doesn’t come without cost to develop such a system. This introduction aims to give you an overview of where to start and to summarize your options. Developing the control system in Simulink has a lot of advantages. You do not need to be an expert programmer, it is easy to understand for others (and the poor team member who has the job in the next season). What is most important: you can use built-in MATLAB functions.

The hardware you use can be very different. Boundary conditions for the processing unit are:

- It must be capable of the data interface, which is used in the car. In most cases that is the CAN-BUS. The computational power must be sufficient.
- There must be a possibility to compile the Simulink model for the unit.
- For telemetry, the hardware should be connected to a radio interface, for example a LAN adapter in combination with a WLAN router.

An example we are considering is the Flea3 by CarMedialab. The C2000 family by Texas Instruments is also worthy to mention. Find here a Racing Lounge blog post for an application of this type of board. Or, you can even use a Raspberry Pi for the job.

A complicated but powerful approach involved systems on a chip (SoC) involving an FPGA. Find here an example from Avnet. The Racing Lounge video podcast also has addressed this topic, showing how to implement a Simulink model on a Xilinx Zynq 7000. With this hardware, you have the possibility to use a FPGA, which is relatively complicated and not necessary at least for a first attempt.

As you can see, there are a lot of possible control units, while the way of implementing your Simulink model differs depending on the hardware. For a first attempt, it can be good to use a Simulink model which directly takes the data from the CAN-BUS. Later I would recommend exporting the Simulink model with Simulink Coder and implement it in another control unit Software, which is also able to use telemetry data. This way, you can quickly change parameters without re-flashing. That saves a lot of test time.

__Mandatory Sensors:__**Steering angle sensor**

The most important sensor for the torque vectoring model. Steering angle is important for defining target value, such as target yaw moment (well, that is one option) but also for calculating a vehicle model.**Throttle pedal sensor**

This input has to be used to determine the longitudinal acceleration of the car. One has several options here: Either, it can be proportional to a sum of motor torques, factorized by a torque ratio, calculated by the torque vectoring system. Alternatively, the input is proportional to a target longitudinal acceleration as input for the torque vectoring.**Brake pressure sensor**

The brake pressure is needed to determine whether the motor torques work against the brakes. Then the torque must be reduced or set to zero. Therefore, it is good to know which torque is distributed from the brakes, dependent on brake pressure.**Electrical brake sensor**

There are two options for recuperation sensors. You can use a spring and a sensor comparable to your throttle pedal sensor. Alternatively, you can use a sensor which measures the force the driver distributes on the pedal. Most drivers prefer the second option, but it is more complicated to implement. Again, you must consider which variable is varied in your control model.**Motor rotational speed encoders**

These are very important for traction control and some other calculations. There is no need of extra wheel speed sensors. Taking the gear ratio into account is absolutely enough.**Battery voltage and battery current**

Limiting Power to 80 kW can be done by a controller. For that you need the current power. These sensors can also be interesting for different recuperation strategies.

__Optional Sensors:__**Inertial measurement unit**(IMU)

Although not mandatory, an IMU is very important for a good control system. It contains at least an acceleration sensor and a gyroscope. Wheel loads can be calculated using accelerations. Yaw rate is a very important quantity which is calculated from the gyroscope data. For calculating an own reference speed (which doesn’t come for free in 4WD cars), it is mandatory. If you do not have the possibility to develop an IMU on your own, take an existing one and adapt a CAN interface on it, such as in that example.**GPS**

Not necessary for the control system if you do not want to calculate a reference speed on your own. If you want to calculate a reference speed a differential GPS (dGPS) is the better way.**Push- / pullrod load cell or strain gauge**

This is nice to have not only for your wheel loads in your control system, but also for other validations on your car. However, especially strain gauges are hard to implement. Normally it is also enough to calculate wheel loads using IMU data.**Optical speed sensor**

If you can manage to get an optical speed sensor, e.g. Kistler Correvit, for reference speed and side slip angle as a sponsoring, do not hesitate. Alternatives are GeneSys ADMA and VBOX Speed Sensors.

Most of the data you get from your sensors is noisy. For further implementations, filtering is required. Mostly, a low-pass filter is the best choice. You can decide between a finite impulse response (FIR) filter, which is a moving average, or an infinite impulse response (IIR) filter. Moving average works for us perfectly for steering angle, gyroscope data, and wheel speeds. There is no need for more advanced filters. However, make sure you take phase shift into account, which can have huge effects. Custom filters can be designed, which could look like this for a FIR filter:

FIR-Filter

Another possibility is to use low-pass filter blocks from Simulink.

Differentiating noisy signals requires more computational effort . Finite difference methods such as difference quotient or central differencing scheme (preferred) work well and almost without phase shifts. On the downside, these filters also work as high-pass filters and hence increase noise. For example, a MATLAB implementation of central differencing looks like this:

diff_central = (f-f2)/(2*dt); % f : value to be differentiated % f2: value of the second last time step % dt: duration of one time step

We have been using this slightly more complicated differentiating method for real time applications. For us, it works very well with small phase shifts and low noise. For steering angle, we were even able to calculate the second derivative (orange) basically without noise. You can also see the first derivative calculated with difference quotient method (yellow) and with the filter (blue). Find here a link to the model on File Exchange: Real time derivation filter.

Steering angle time signal; calculated first and second derivative

The system implements the resulting formulae of the paper. It calculates the derivatives without the use of loops. The needed inputs are the signal to derive and the duration of the (fixed) time step.

Kistler Correvit system installed on race-car

If you managed to get an optical sensor from Kistler you will not have any problems at this point.

All others must face a difficult issue. The problem is clear: A four-wheel driven car cannot take solely wheel speed data to calculate a reference speed, because all four wheels have slip. Side slip angle cannot be directly measured.

In the beginning, you may take only GPS reference speed or built up a reference speed estimator based on wheel speeds and integrated longitudinal acceleration data and assume the side slip angle to be zero. But you will notice the limits of such systems after a short time.

To manage this, some complex data fusion must be done to calculate both reference speed and side slip angle. One attempt is to use neural networks. The problem here is that you already need a lot of data with measured reference speed and side slip angle (e.g., from an optical sensor) to train the network. Furthermore, the system will differ dependent on the car, which means that you will not be able to use it every season. Another possibility is to do data fusion based on an extended Kalman filter. An introduction to Kalman filters can be found here.

The extended Kalman filter does not need measured data and can be adapted on car parameters, but it will be heavy to let it work as good as a neural network. It is very important to have a detailed update matrix, describing the whole two-dimensional vehicle dynamics. More sensors make the Kalman filter more accurate. One idea would be to take wheel speeds, IMU data and GPS position.

Validation of such systems is still heavy without being able to measure reference speed and side slip angle. So, I suggest investing some effort in getting an optical sensor.

Another major and often underestimated topic in race-car control system design is power management.

One part of it is recuperation. The maximum recuperation torque must be limited concerning battery voltage. While the car is braking, battery voltage increases because of the internal resistance of the battery cells. When beginning to drive, the battery usually is fully charged. Hence, it is impossible to use the maximum recuperation current as the battery voltage can go above the maximum value. Therefore, you need to slightly increase recuperation power at the beginning of endurance. One way to do that is to integrate the used electrical power. Then you can multiply it with a factor and get the slightly increasing maximum of recuperation power. If the recuperation power is at recuperation current maximum, it stops to increase. Find here a link to the model on File Exchange: EV recuperation limitation -> “recup.slx”. Surprisingly, this (simple) system works very well.

Another possibility is to build up a battery model. Based on an equivalent circuit model for your cells, it is possible to predict the increase of voltage, dependent on recuperation current. This approach allows to determine which recuperation current can be used in maximum to reach exactly the maximum voltage of your cells. This video shows how to build up a battery model.

Building up a battery model is not easy, and the advantages compared to other systems is difficult to measure. However, it shows you how your battery works and there is a huge interest in design event. For both systems, I would strongly recommend implementing a controller, which hardly reduces battery current when you get over your maximum battery voltage. In our case a simple propoertional controller did the job.

Now, you know your maximum (and maximum negative) electrical power measured by the energy meter. With a loss model of power electronics, your motors and gears, it is possible to calculate the maximum mechanical power. With the current wheel speeds (which do not differ too much between the time steps) a maximum sum of motor torques can be calculated. The torque vectoring system then distributes this sum. It is also possible to limit the torques after the torque vectoring system, while not changing the torque ratio.The choice depends on the torque vectoring.

This is a feed-forward system for the power management. The target is to get as near as possible to 80kW while not violating the rules. If you get over your maximum power with this system, it is also possible to adapt the maximum limit with a controller. Again, a simple P controller can be a first attempt.

During endurance, you will not be able to drive with 80 kW all the time. For that, the maximum power can be adapted. Most teams just set a new maximum (e.g. 50 kW) and drive through endurance with this new limit. A more advanced method is to accelerate with more power and limit it when reaching a certain speed.

Torque vectoring makes your car fast!

Our car for example is roughly 0.4 seconds faster in skidpad with torque vectoring.

This is done in two ways: Firstly, torque vectoring can stabilize the vehicle or make it more agile. This is comparable to an ESP. Secondly, it enhances the vehicle’s grip during cornering. How this works is shown in this video.

A simple attempt, which is easy to test in the beginning, is this one: Set a constant front / rear torque distribution and calculate a left right distribution ratio on proportional to the steering angle. Even this simple system can decrease lap time significantly, when it is setup up appropriate.

Other, more advanced, systems always have (as far as I know) a layout like this:

The driver’s inputs, which are steering angle and throttle pedal position, must be translated into variables that can be used in vehicle dynamics calculations. These are a target yaw moment and a desired longitudinal acceleration or sum of motor torques. The desired acceleration is just set proportional to the throttle pedal. Yaw moment is more complicated. An often used and well-known attempt is to apply a yaw rate controller, which sets the target yaw moment. The target yaw rate can be calculated from Ackermann geometry or optimizations on a steady state vehicle model. A yaw rate controller is especially suitable for inexperienced drivers who are not used to a vehicle swinging off. More experienced drivers sometimes feel limited when driving with a yaw rate controller. For them you can use an easier approach: just set the yaw moment proportional to steering angle and its derivative. And there are a lot more possibilities to do that. If torque distribution properly sets the yaw moment, one has a more agile or more stable car, depending on the driving situation. The task for torque distribution is to fulfill the driver’s targets, while maximizing lateral acceleration simultaneously. This calculation should be based on a double track vehicle model. Again, there are a lot of options, how to do that. The optimization can be done in real time on the vehicle, going from tire to tire and increasing its load to the maximum. Another possibility is to optimize steer angle and motor torques offline on a steady state vehicle model and put them into the Simulink model as a lookup table.

For testing of suspension and aerodynamics it should be possible to turn off torque vectoring and use the same torque on the left and right track.

This picture shows a control system without traction control. Right after the torque vectoring system, the torques are sent from the control unit to the power electronics. When the driver pushes the throttle fully from standing, the torque vectoring sets (if there is no feedforward in torque vectoring system) motor torques to 100 percent. The power electronics will control the current given from a motor map and wheels will start to spin. That is why we need traction control.

It is still a good idea to have a switch on the steering wheel for powering off traction control. For example, if you are testing a new torque vectoring system, traction control changing torques all the time isn’t actually desired. Let your driver review your traction control with a comparison between driving with it and without it. Does it limit the torque too much?

For traction control you need to add two more systems: tire model and speed controller. The tire model is needed to calculate your target slip from the torques, this is also called an “inverse tire model”, because normally a tire model works in the other direction: from slip to force/torque. This inversion is easier to do with TMeasy than with a Pacejka model. Find here a video on tire modelling.

**[VIDEO] **MATLAB and Simulink Racing Lounge “MATLAB and Simulink Racing Lounge: Tire Modeling; Extracting Results from a Large Data Set“

Notice that your tire forces are highly dependent on wheel loads. Your calculation (or measurement) for that should be precise. However, if you really do not have time for building up a tire model, you can also use a linear approach between slip and force/torque.

With your current reference speed and yaw rate you can calculate your tire’s mass point velocity. By adding slip, you have calculated the target wheel speeds.

Now there are normally two possibilities. Most power electronics have an implemented speed controller. You can take that one (speed controlled), or built up another speed controller in your main control system which only begins to control, when a slip is measured, which is higher than your maximum target slip. This is called torque controlled.

At first it is easier to drive torque controlled. Real torques do not vary too much from the target torques, which means that you can be sure faults can be found in the torque vectoring system. A good reference speed is not as important as in a speed controlled system. As a speed controller, I would recommend a PI controller with some kind of anti-windup.

However, a speed controller which is not running on the power electronics will always be worse: The power electronics is directly connected to the motor’s rotational speed encoders. In this way, the controller can reach a much higher frequency and is much more precise.

There are some other problems you must consider:

Reference speed and slip can be noisy. So, your target wheel speed will be noisy too. What happens if you do not push the throttle? Most power electronics can limit their speed controller output to a certain torque, which you can send via CAN too. It is also a very good idea to use that for power limitation.

Another problem is that most of the speed controllers on power electronics are also PI controllers, which have a huge offset between target speed and measured speed, when using them in such a dynamic process like speed controlling. This means if you want to get the same torque output as in torque controlled mode, you may have to add an offset on the target speed. These offsets must be adapted such that you get out the same torque from the speed controller as it is calculated in torque vectoring when you are not driving at the tire’s maximum.

I hope you find our reasoning a little helpful.

Greetings from Karlsruhe with a very noisy “POWER FUEL!”

Best, Julian

]]>Sebastian Castro is back to talk about the basics of connecting MATLAB and Simulink with the Robot Operating System (ROS). Overview Robot Operating System (or ROS) is a commonly used framework for designing complex robotic systems. It is popular for building distributed robot software systems, as well as for its integration with packages... read more >>

]]>Robot Operating System (or ROS) is a commonly used framework for designing complex robotic systems. It is popular for building distributed robot software systems, as well as for its integration with packages for simulation, visualization, robotics algorithms, and more. ROS has become increasingly popular in industry as well, especially in the development of autonomous vehicles.

As of R2015a, Robotics System Toolbox has equipped MATLAB and Simulink with an official interface to ROS. This interface lets you:

- Connect to ROS from any operating system supported by MATLAB and Simulink
- Leverage built-in functionality in MathWorks toolboxes – for example, control systems, computer vision, machine learning, signal processing, and state machine design
- Automatically generate standalone C++ based ROS nodes from algorithms designed in MATLAB and Simulink

In summary, MATLAB and Simulink can coexist with your ROS based workflow via desktop prototyping, deployment of standalone ROS nodes, or both. If you are looking to design even one small component of your system in MATLAB and Simulink, keep reading!

Robotics System Toolbox provides an interface for MATLAB scripting and desktop prototyping with ROS. This includes functionality for:

- Starting or connecting to a ROS master
- Working with topics (publish/subscribe), services, actions, and the parameter server
- Reading specialized messages (e.g., images, lidar scans, point clouds, and occupancy grids)

A simple MATLAB code snippet for a publish and subscribe based control algorithm looks as follows.

In the example above, the algorithm is managed using a while-loop, which means the loop iterations are processed as quickly as possible. There are a few additional ways to schedule the execution of MATLAB code.

**Rates:**You can use Rate and rosrate to slow down the control loop based on the CPU wall clock or the ROS master clock, respectively.**Timers:**Creating MATLAB timer objects lets you schedule function calls on different schedules without blocking. This means you can have multiple timers running in the background while still having access to the MATLAB command window.

**NOTE:** All the code running in timers and ROS subscriber callbacks will execute within a single thread, since the MATLAB environment is single-threaded to users (although several built-in functions use multithreading internally).

For more information on the MATLAB interface to ROS, watch the following video.

[VIDEO] MATLAB and Simulink Robotics Arena: Getting Started with MATLAB and ROS

Robotics System Toolbox also includes a Simulink block library for ROS connectivity. This includes functionality for:

- Working with topics (publish/subscribe) and the parameter server
- Representing ROS messages as Simulink bus signals for graphical programming
- Reading specialized messages (e.g., images and point clouds)

With Simulink, you can take advantage of block sample times and rate transitions to build multirate algorithms, as shown below.

Another benefit of the Simulink is the ability to combine MATLAB, Simulink, and Stateflow modeling language for different algorithm components.

**MATLAB**code is good for components best expressed with textual programming, such as array/matrix operations and machine learning. If you have algorithms written in MATLAB, you can call them in Simulink using MATLAB Function blocks.**Simulink**blocks are good for control algorithms, which are usually expressed as block diagrams. You can also take advantage of built-in block libraries for signal processing, computer vision, robotics algorithms, and more.**Stateflow**charts are good for decision-based logic, state machines, tabular logic, and time-based or event-based scheduling.

For more information on the Simulink interface to ROS, watch the following video.

[VIDEO] MATLAB and Simulink Robotics Arena: Getting Started with Simulink and ROS

We discussed how MATLAB and Simulink can help you design and verify robotics algorithms from your desktop. Even if your robot’s onboard computer meets the requirements to install and run MATLAB, you probably don’t need the overhead of these design and verification tools on the final system. On the other hand, installing MATLAB is completely out of the question for low-cost ROS enabled platforms such as Raspberry Pi.

As you transition to your final implementation, you could manually port the MATLAB and Simulink prototype algorithms to work on your robot. Alternatively, you could consider automating this process with code generation. This can speed up the development process and remove manual implementation errors.

The two code generation approaches are:

**Generate reusable code:**Use MATLAB Coder, Simulink Coder, and Embedded Coder to generate standalone C/C++ files or libraries from MATLAB files and Simulink models. This approach is flexible, in that you can integrate the generated code with any framework you may already have in place, but it still involves some manual effort to get running.**Generate ROS nodes**: With Robotics System Toolbox, you can directly generate C++ based ROS nodes from Simulink models (and recall that MATLAB code can be called from Simulink models). Compared to the previous approach, which generates entry points to your algorithm, this generated code will also include ROS functionality (publishing, subscribing, etc.) and algorithm scheduling based on the sample times specified in the model.

The ROS node generation approach can also automate the process beyond generating code, as shown below. This includes moving files into the target system’s, compiling the files using the catkin build system, and running the generated executable node.

Once you’ve generated a ROS node from Simulink, there are a few ways you can work with it.

- Start and stop the node from MATLAB using rosdevice, or run it directly from your ROS machine by finding the generated executable or using the rosrun
- Use External mode to tune parameters and visualize data directly in the Simulink model, even though the code itself is running on the target computer. The code will be generated with a TCP/IP interface to your Simulink model running on the desktop. While this has some processing overhead, it can be a good debugging step while you are still designing your algorithm.
- Configure your algorithm to send or receive ROS messages or values in the parameter server. This lets you interact with the deployed node from MATLAB, Simulink, or other ROS nodes and the terminal on your target machine.

For more information on deploying algorithms as standalone ROS nodes, and using the deployed nodes, watch the following videos.

__MATLAB and Simulink Robotics Arena: Deploying Algorithms to ROS
__

You have seen an overview of how algorithms can be prototyped in MATLAB and Simulink, and how they can then become standalone C++ based ROS nodes. If you’d like to know more, leave us a comment or post on our Facebook group.

You can download the templates and examples shown in the videos from the MATLAB Central File Exchange. The virtual machine used in the examples can be downloaded from the MathWorks Web site.

– Sebastian

*An example of MATLAB and Simulink interfacing with ROS, as shown by the ROS utility rqt_graph.*