Today’s guest post is by Brandon Stevens. Brandon is a ECE graduate student who serves as the Propulsion Controls and Modeling lead for the University of Alabama (UA) EcoCAR Mobility Challenge team. This competition challenges 11 North American universities to build and develop code for a fuel efficient prototype hybrid and SAE level 2 autonomous vehicle. Specifically, a stock 2019 Chevrolet Blazer is re-engineered to include a high voltage electric motor system, a new engine and transmission, plus new cameras and sensors to help facilitate longitudinal and limited lateral control. To carry out these controls, a new computer is placed in the vehicle to provide supervisory control over the other vehicle components. This Blog is a 2 part deal: in our first post Brandon will discuss why his team needed to revamp their controls development and detail how they use MATLAB projects, and in our follow up he will cover how their team uses version control and componentizes their models for easier development.

The UA team finished 1st overall in the Year 3 Competition as well as winning the Best Propulsion Controls and Modeling presentation, 1st in the industry dSPACE Leadership in Validation Award, and 2nd place in the MathWorks Model-Based award. In this blog Brandon describes how the team used MathWorks tools to organize their complex MATLAB and Simulink code to enable teamwide collaboration and success.

For developing our control code, the team uses MathWorks tools for Model-Based Design to design, iterate, test, simulate, and automatically produce code that goes onto their in-vehicle computer. This is not a simple nor one person task for our university team, and thus the UA EcoCAR team overall contains 65 members today. 13 members are dedicated to the controls team, where development of software is done to connect in and control the car, in addition to improving drive quality, fuel efficiency, and safety. It’s a big student design team to work on one software project and we use Model-Based Design to accomplish all of it.

With an ever growing team and more developers, we recognized that our old ways of creating Simulink models was not going to cut it. When we only had 2 developers, it was easy to keep the up-to-date code on one computer with zip file backups. It wasn’t a big deal to manually run some MATLAB scripts to setup some variables. We worked mainly in one big Simulink model and we had no way to really check what was actually changing in our code.

As our team grew during the last year we ran into big issues with our simple system when trying to combine code changes or divide out software tasks. We really did not know how to effectively work as a team at all in MATLAB and Simulink, so we spent some time learning and applying better software practices and the structure of our code to make it much easier. We upgraded our code in many ways to improve our workflow and remove a lot of the headaches of trying to integrate everyone’s code together and to enable people to try new things.

First, we used Projects to organize our models and make it amazingly easy to share our models with new members. New developers simply needed to open the project file and all the setup steps were automatically done. We added project shortcuts to give a single button in MATLAB to hit to open the correct Simulink file for what they were trying to work on.

Projects also give a great built-in Graphic User Interface (GUI) to version control software like Git inside MATLAB. Leveraging this GUI meant new members did not need to learn how to navigate a Command Line Interface (CLI) to do anything with Git on our model, and we began to really use Git and see the benefits of version control. Team members were able to work effectively both in our team’s office as well as at their apartment or home over school breaks. Furthermore, with the use of modern version control, we also moved to take on other updated software development principles.

Finally, we re-factored our code to componentize it, or to break our one big Simulink model with thousands of blocks into many that each consist of different functional pieces. This was revolutionary to our team to get more developers involved early on and allowed for huge improvements in enabling collaboration, reusing code, and speeding up testing and the automatic code generation process. For example, instead of placing our big controller code into one subsystem we instead spliced up that code into various model reference which can be edited and ran on their own. We like to color code these and some are shown below.

Projects were the simplest and perhaps most impactful improvement to our workflow that we embraced this year. A project file wraps around all of our data files, tests, and MATLAB and Simulink code to automate a lot of our workflow that we use, including startup and shutdown tasks. We have added different MATLAB scripts to the startup and shutdown task lists in Projects; this means that on opening the project file the startup script is run which pre-loads some of our key variables in the workspace, and assures our MATLAB environment is setup correctly. If one of our developers was working on some engineering coursework, they can open the Project file and anything they were working on won’t interfere with the EcoCAR model, and when they close the project the EcoCAR models won’t be in the way. These setup tasks have been great in speeding up our onboarding of team developers; new members simply needed to open the project file, those scripts would be automatically run to setup the environment, in addition to adding all the relevant Simulink and MATLAB files to the MATLAB path. Those project shortcuts shown earlier means it is simple to jump into the right model to get to work or to run a simulation. Years ago, our Controls team new member “training” was to figure out how to setup and run a model, and now that is a non-issue.

Projects also include a graphical user interface (GUI) to interact with most common version control systems like Git. We had previously tried version controlling our Simulink models with Git and interacted it solely through a command line tool. This meant it was non-intuitive for most of our engineering members and was very rarely and poorly used. With a well-structured project, we were able to leverage the Projects GUI to use Git properly and make it super easy for us to make it practical.

Our team uses a university hosted GitLab server to manage our Git repositories and the project work being developed. This functional Projects Git interface system and simple to use GUI means every developer works on feature branches that they become “squashed and merged” onto a main development branch. With our model now compartmentalized, our process of merging and maintaining a file change list for each feature has also been simplified. Below is part of the Projects source control GUI which shows our log of changes and merges of feature branches into our main branch before and after moving our version control into the Projects UI.

Projects and the version control GUI enabled us to build this up and it’s been incredibly helpful to have this history of changes and useful Git commit messages. Every time before we add new code we compare the files to see how it changed to the most recent version through the compare tool. When working on some code, we can also look at the history of the file to help figure out who made the changes, and why some system works like it does right now.

In Part 2, Brandon will cover how his team went about breaking down their large Models into components to help their version control process.