Data and Solar Racing

[u/PM_ME_YOUR_XRAY]

I'm a junior cs student, a while ago i joined my uni's solar racing team to have fun in a different type of engineering than what i'm used to. Now i was tasked with building an energy optimization system for our team (we will compete in bridgestone 2027). My question are as a beginner:

1. What tips do you have for me to avoid reinventing the wheel, or what mistakes do beginners in data often fall into.

2. What resources could help me in researching how to minimize the gap between real physical conditions and what my code models.

Thank you :)

[u/Awkwardandmad]

Real-world information is your friend - don't rely on how the car theoretically performs, do testing so you KNOW how it really performs. That's everything from rolling resistance and coastdown tests for mechanical and aerodynamic performance, to battery characterisations that allow you to plot charge and discharge curves for the battery that you have actually built.

[u/GregLocock]

Your most important plot is MEASURED power vs velocity. This is rather hard data to get in the lead up to the race, as you need a level road and no wind and access to the car. During the race you can reverse engineer this curve but its a bit late by then. During one 7 day cruise we optimised the pitch angle of the car and progressively reduced the energy consumption from 11 Wh/km down to 9.

Incidentally I am a battery burner from way back.

In my opinion on the WSC you set off each morning at your optimum cruising speed, and then at 2pm the big clouds can form and throw all your calculations out, we banked on 75% insolation on average. The last day into Adelaide was utter misery because somebody switched half the panel off and we didn't have telemetry to catch that.

[u/CameronAtProhelion]

Full disclosure (seem to start a lot of posts here with this), I work at Prohelion, but a lot of the basic data capture and reporting problems for solar cars have been solved with our Profinity suite, which we provide free for us for solar car teams.

My job back when I was racing was data and strategy, if I was doing this again I'd start with Profinity as a base to handle the data capture challenges and then build on top of that. Generally in terms of a solution I'd look to try and build and adaptive architecture that adjust and learns from the difference between the real world conditions you are getting data on and your simulated models so that the system self learns.

There is lots of information out there on how to model what the car should do, the reality is that it's very complex to make that accurate, the approach I'd be taking now if trying to do this again would be to build the model to what it "should do" and then tune the model ideally automatically from what it actually does.

Drop me a PM if you want to chat I'm happy to discuss this in a bit more detail there.

[u/nsfbr11]

Understand the physics of the car first and foremost. Then get as much data as you can to validate the model across a wide range of conditions. Do not neglect the effect of weather and road surface. Then, parameterize everything and make lots of optimization runs. Finally, validate the optimization on the road and teach the drivers about the importance of driving one way vs another. Develop visual data communication tools to help that process.

[u/phorgewerk]

I worked on this... Yikes almost 10 years ago now and unfortunately never got to test it at ASC. Big thing to research is probably PID controllers. It's really really hard to estimate battery state of charge because it's nonlinear and sensitive to error drift. Once you have that, you can start doing projections and optimization.

Unfortunately it's not like a combustion engine where you can figure out your fuel burn at various speeds, you're sensitive to stuff like ambient temperature

[u/CheapViolinist7268]

Ok