260118 - Update for 2026

MD25 was a huge achievement for the team, being able to bring a functional car to competition. Passing accumulator tech inspection was also a significant challenge that we managed to achieve as a team. Overall the electrical subsystem last year was functional but it still had a few teething issues that we hopefully can resolve for MD26. The goal for MD26 will be to try take as many of the systems that worked last year and improve the systems to make them more reliable and robust. I am cautious to make too much major changes to the electrical subsystem, noting in mind the lack of time that the team had at the end of the year. The goal should be to get the car into a driving state around open day next year. It is very optimistic but if we aim for that, worse case the car should be done by around the end of blue book. I will come out with harder dates later. This would give us time to test, as well as find out all the issues and ensure rules compliance. Hopefully this will mean that we are able to participate in the dynamic events this year.

The main priority is to clear some of the technical debt from past years. The lack of documentation and calculations were an issue at comp as well as for new members, it was a struggle to find information. The goal this year is to set up a good system of documentation and continue to use it for the rest of the year, that is this platform hopefully.  Overall changes in the electrical subsystem should be made with caution and a fall back plan in mind. I am currently working on slowly transferring all the information scattered on the teams page to this platform. My main gripe with teams is that it isn't really designed to store information and organise it like Bookstack, and CAD and other stuff ends up mixed with the documentation. It should have one job and it should be able to do it well. It is very annoying to have to go through like 50 folders to find something where hopefully once Bookstack is fully setup, everything should be easier to find. All important documents will be stored on teams still, but it will used for file storage, not documentation.

The vehicle functioned last year but didn't pass tech inspection. Overall if the subsystem is the same performance standards with better reliability and  maintenance, the vehicle should be considered successful. The aim is to emulate the performance of the University of New Castle, running a similar set up to ours with the exception of a 450v TS. They performed very well placing highly across all dynamic events. That would be our performance goal.

Learning and teaching

As a part of the non technical goals, a training program to up skill new members should be developed. The electrical team is quite small, and I hope that we can get more people to join and stay. I am working on some new member projects that I think they can learn from as well as some of them being able to be used on the car. Electrical work on the vehicle has a quite steep learning curve which makes it difficult to teach things. It will be a balance of teaching and not overloading with too much info, as most stuff will be taught in second year.

Hopefully we are also able to get some software guys, it would allow the elecs to focus on designing hardware while the software guys can work on code to make the code reliable and add more features. The SCUM has data logging however no code yet to do it, same as the charger box. It would also be nice to have some software people to maintain the server for this documentation platform

Technical changes

There are a few items that will be the main focus for MD26. The priority is the accumulator redesign. Although we passed scrutineering, many of the aspects of the accumulator are not ideal. For example getting each segment in and out wasn't user friendly as well as the many modification made to the accumulator at competition. There are plans on changing the configuration of the Enepaq modules. Currently the configuration of a segment is 22s 4p. However this configuration creates very blocky segments or a super long segment. Both of these aren't the best configuration. This creates challenges with mechanical integration. These could be mitigated but it increases the complexity of the design, making it difficult. A different configuration that was being considered was 14s 4p or 16s 4p. This would mean more segment, however, the rumour mill says that there will be rules IRT max segment voltage, being limited to 60v (Not sure if nominal or max). This would mean working in LV which makes it easier. This would still mean switching from the Orion BMS. This means that this a good time to move to a distributed architecture, allowing for more segments. Again it is a rumour, 

The main limitation the design is the Orion BMS, only allowing up to 4 different segments. To mitigate this issue, we are looking into using the Enepaq TinyAFE. This will function as cell management units (CMU) attached to each segment. Then the next challenge is the development of a battery management unit (BMU). The TinyAFE requeires a custom BMU or a existing BMU that needs to be translated to work with the TinyAFE communication protocol. Currently the two potential options are to develop our own or use the existing Prohelion and write something to translate. But I think at the point we write a translation utility we might as well write our own BMU. This will be very complex and involve lots of testing to make sure it can pass tech inspection. If this is the method that we go it will be the main priority. There is also the option to run the same configuration with the Orion BMS 2. The BMS by itself is a good system with good software but it will still involve designing a temperature sensor module to interface with the Orion. If we use the Enepaq TinyAFE there will be less of a issue. This development however can be done in parallel for MD27, however the issue is I am afraid it will detract from MD26.

One of the main things to improve next year from the low voltage side is using the Motec C185 dashboard. The dashboard is very powerful with many features. The plan is to use it as a main node in the vehicle architecture, receiving inputs such as APPS and doing prepossessing as well as logging all the sensor data. The C185 is significantly more powerful that most dashboard that other teams use and could handle most very basic ECU functions (At least in the MD25). Then any other data will be communicated over CAN to the SCUM. This will be a big change and I am cautious, and it will be the first priority to experiment with it and see if we are able to get it working. If the system is set up, it would mean the for future iterations the system will be significantly better. Worse case, we can develop our own can node to do the basic functions like sending information over can bus and doing logging. The main channlage will be integration hell. I have been playing around with it and it does seem alright. I will continue messing around with it when I am free. 

In addition to this, the SCUM needs to be updated, the Amphenol connectors are only rated to 250V, meaning the TSAL circuit will need to be moved to a independent board with rated connectors. This means there will need to be a minor SCUM redesign. I am very cautious with the SCUM, it is well designed and there aren't really any major issues with it, but because we don't have any more boards and the issue with the TSAL, it would be worth it make a few minor changes and order more boards. More GPIOs are needed as well, reading values from the shutdown circuit to know the state of the car. This will be done on PCB, as other teams need to do it off board on their ECU, but the SCUM is a integrated system. It is being considered to develop our own mcu board with a stm32g4. This will have all the peripherals required for all functions. However a off the shelf solution will always be easier. In addition to this, there is a ready to move light rule in the 2026 rules, however unsure if it will be our rules this year.

Currently I am also in talks with SBG system to get a INS (Inertia navigation system). This would be used for data logging/ vehicle dynamics analysis but most importantly for traction control. This will help with points in design as the decisions that we make can be justified with real data. This means that basic vehicle dynamics model should be made. UQR has a very advanced model developed for a thesis to do this. This means that every change they could make to the car can be seen in a measurable point increase. For our purposes a point mass system will suffice. This most likely be handed to a mech to build something in matlab, unless someone from the elec side is very passionate about matlab.

The traction control system will involve having a board that will process all the signals and send it to the SCUM. The most important thing that we want is the true vehicle ground speed. If our true vehicle ground speed is slower than the motor speed it means that there is slipping in the wheels. To prevent this, the best way would be to modulate the throttle signal to be lower (EV.3.1.3). This would mean setting the target RPM to be just a bit higher than the current RPM. It is acknoledge that we are using current control for the inverter, meaning that we can't set a target RPM, but using the INS can can calculate the values required to change the speed by x amount. Another simpler method that might be more finicky is to hard code PID values through testing to get the proper traction control values. Traction control isn't needed to finish dynamic events so it will be on the back log for a while, if anyone is interested it will be a good solution.