One of the most significant tasks in developing a successful control system is calibration. Companies often have large teams responsible for calibration alone, and the result is more often than not “good enough” as it is extremely hard to find an optimal calibration. We believe that the best approach of calibration involves gaining an understanding of your system, work systematically, and to test a different set of calibrations repeatedly.
The first part of the calibration done in simulation is often relatively easy, as one can see the result of a change in a parameter almost instantly. In practice, however, one often needs to compile and upload everything to the ECU in question for only a small parameter change. This approach is both time-consuming and complicated. As there exist few free of charge softwares tackling this problem, for smaller companies that do not have the same amount of resources, or for control engineers as well as students that develop control systems on their free time, this task grows even more demanding. To address this issue, we developed an application in which one can conveniently see the results of the calibration in real-time. Below, we will describe the concept of the application and how to use it.
Connection
To minimize the performance impact of the users’ ECU (further on referenced as a unit), the application communicates to a small external real-time device over Bluetooth. The wiring consists of connecting two wires to a UART port of the unit as well as positive and negative power. All communication is handle in the c++ library, so all the user needs to do is to call the basic library functions. If the user has performance to spare and an unused Bluetooth socket, it is possible to skip the external device and set up a Bluetooth connection directly to the unit.
Calibration
Once connected to the device, the user can start to calibrate, which is done in the Calibration fragment of the application, see Figure 2.a. The calibration is done by adjusting the so-called “Tunebars”, either by directly writing the desired value or by dragging the bar left or right. Every time a value has been changed, the application will notify the change to the unit. For us at Combine, user customizability is a big deal, so the user can either add any number of custom Tunebars using an arbitrary parameter name or remove any Tunebars that are unnecessary, by pressing the “+” or “-“ buttons. Hence, the user can calibrate any arbitrary parameter the unit uses in real-time.
To enable both parameter identification and fine-tuning, the precision of the Tunebar can be adjusted by changing its factor. By doing this, one can start with finding an approximal parameter value using a large factor. Once found, one can set the approximated value as an offset and fine-tune it using a lower factor, see Figure 2.b.
One can also add any number of buttons, controlling either so-called “Main States” or “Modes”, see Figure 2.c. The Main States are defined as a mutually exclusive state that the device is acting in. This function is meant for the user to easily switch between control states that can only be activated one at a time, such as “start”, “stop”, or “cruise”. The modes, however, are not mutually exclusive and can be used to activate specific functions the user may have, e.g., switch on a light or activate a specific control objective. The Main States and the modes can be accessed through the navigation bar as well, to easily switch between them in all fragments of the application, see Figure 3.a. The user can define any number of arbitrary Main States and Modes through the c++ library.
Finally, once the user has found a satisfactory calibration, or want to save the customized Tunebars and buttons, the layout with the current combination of Tunebars and each corresponding parameter value can be saved to be loaded in a later instance, see Figure 2.d. This way, the user can quickly go back to another combination of calibration values and compare what effect a specific change of parameter tuning had.
Plot
In most cases, the human eye alone is not sufficient to decide whether a specific calibration is better or worse than another. For this reason, we added a plot function to the application as well. It can be accessed through the navigation bar, see Figure 3.a. The plot works by the user specifying what signals he or she is interested in observing. By specifying the pointers to these signals using the c++ library, the signals will automatically appear in a list in the plot fragment of the application, see Figure 3.b. In this dialog, the user can then choose what signal to plot and some plotting customizability. Similar to the calibration fragment, the user can also add or remove any number of plots and scroll between them, see Figure 3.c.
Manual Control and Debug Console
One of the main objectives behind the application was to make it as generic as possible. In many cases, one can imagine sending reference signals as a useful feature. Even though this could be achieved using the Calibration fragment, the user could only give linear reference signals to the unit. There exist many systems in which angles and power are used as references, so we decided to include these cases in the initial release of the application. Thus, we created a fragment in which the user can give manual control references using a joystick yielding a steering angle and a reference power. To increase the customizability, one can specify how the joystick should work. For instance, the user can redefine the angle range in case the system has a hardware limit or redefine the angle depending in which quadrant the joystick is in. This can be achieved by defining the angle in one, two, or all four quadrants, see Figure 4.a. For quick access to the Main States and the Modes, the option to add buttons in this fragment was added as well. For a quick setup of the joystick and the buttons, we implemented a save and load function here as well.
Finally, for the user to have full control over the unit, we also decided to add a debug console prompt. In this console, the user can transmit any message from the application to the unit or the other way around. Utilizing this, the user can define own commands in which the unit should respond in a specific way, see Figure 4.b. It can also be used as a debug console in which the unit transmits the status that the user wishes to observe. For easy observation, we decided to add the debug console to the Manual Control fragment. However, we also added it as a fragment of its own in order to get a larger prompt, see Figure 4.d.
The source code of the project can be found on our GitHub page, see https://github.com/combine-control-systems/combine-connect.
Happy calibration!