I'm Rutger van den Berg, member of the Software team. In my last post, I talked about what software needs to be written to actually get a driving car. This includes drivers, integrating control systems and safety systems.
Of course just getting a driving car is one thing, and is, as it should be, the first priority. After this though, we aim to make things as easy as possible for the rest of the team. For example, when you have sensors on any system, you're probably going to need to calibrate them. You can implement this quite easily by hardcoding the range of the sensor and adjusting the measurements that way. As anyone participating in Formula Student can probably tell you, FS cars change quite often. This means you might be recalibrating (and therefore changing the code, re-flashing it) several times a day. This takes time and effort during the testing phase, time that could be used more efficiently for actually testing the car. The same thing goes for other settings, such as control system parameters. It would be much more convenient to be able to change these on the fly, through our dashboard interface. Of course this brings to light other issues, such as where are you going to save the data, and how often? How do you reliably move this data between the ECU and the Dashboard?
Similarly, it is convenient to be able to easily check the functionality of various systems while diagnosing a problem. The simplest way of course would be to disconnect the systems and check whether the individual components do their job properly. Again, this takes time. It would save a lot of time if we could just toggle various individual systems on and off in some type of diagnostic mode, preferably without re-flashing the car. At first glance this may seem like a trivial feature to implement. But then you realise that all of these systems are interconnected, and if you turn one off it is very likely that some other system might unexpectedly break. This means you have to carefully design temporary replacements that ensure that turning off a single system does not break the others.
These are just a few examples of the software we write, saving the team precious testing time. We are constantly on the lookout for better ways to make things easier on the rest of our team.