I was recently asked to build out a set of drag racing simulation models in Dymola, utilizing the VeSyMA suite of Modelica libraries, that could be used as a demo to show prospective drag racing customers. After all, we haven’t seen much penetration of simulation into this market, and based on our experiences in Formula 1, NASCAR, and IndyCar we certainly believe that simulations are a great tool to help organizations develop high performance vehicles. This task sounded fun to me, so I jumped right in!
Step 1: Acknowledging what you don’t know about drag racing 🙂
My background in drag racing is fairly limited. I’ve spent a few days at the dragstrip as a spectator / helper and have even made a few passes in street cars, but really don’t know all that much about the details, or rules of thumb that most hard core drag racers have developed over the years. Racer’s intuition, developed over time at all levels, for all types of racing, never cease to amaze me. Their feel and predictions for how the car will change based on suspension adjustments, or how the track will evolve with weather and surface changes are impressive!
Fortunately, I have a few friends who spend a decent amount of time at the strip, drag racing their own cars and helping friends/customers tune theirs. Prior to getting started on this endeavor I reached out to some of them to gather as much information as I could. Ultimately, through discussions with these friends I came away with a good bit more understanding than I had previously. (Note: I still don’t know very much about the topic!)
Step 2: Expected challenges (from 30,000 ft)
The levels of grip / traction during launch seem to be highly variable. Chemicals are often applied to the starting box to add grip, so amount of chemical and type of chemical all seem to contribute to traction levels. Add to this, the temperature, levels of sunlight and all the other factors, and it certainly appears to be a complex topic. Under many circumstances I’d highlight this as an opportunity to utilize simulation to get ahead of the competition. However, for this task it seemed better to just shelve it and turn the grip waaaay up and study the impact of CG changes, vehicle weight changes, engine torque, suspension geometry adjustments, etc.. After all, there’s a lot of grip… as noted in the following image.
Often times, during launch, the front wheels are off the ground; thus the driver’s steering wheel input doesn’t do anything. I wasn’t sure how this was going to work with our ‘stock’ driver models. So, I just noted this and waited to see how the simulations performed.
I hope she’s pointed in the right direction!
After some of these initial conversations, it became apparent that suspension geometries and configurations are all over the place. From solid axles to independent rear suspensions, you can find pretty much anything out there. Some cars use coil springs, some use coil-overs, some use leaf springs, and some even use quarter leaf springs with additional links between the axle housing and the chassis. With that said, when you get to the fully fabricated chassis, in the higher powered levels of drag racing, things seem to standardize a bit. From what I’ve seen the most common suspension configuration is a 4 link with a ‘wishbone’. The wishbone is utilized to control the lateral motion of the rear axle, much like a Panhard rod on your common solid axle circle track car. This wishbone isn’t rigid, however, as this would significantly over-constrain the suspension. The wishbone can articulate in roll and is variable length (basically resulting in a cylindrical joint). Since this wishbone configuration seemed to be the most prevalent, and wasn’t something we already had in our suspensions library, I decided to go ahead and model it.
Step 3: Build it!
The rear suspension of these cars, even with the articulating wishbone is mathematically over-constrained. I won’t get into it all that much here, but due to this it is necessary to introduce at least one extra degree of freedom (with a high stiffness which results in a nearly rigid link) in at least one of the 4 links. I chose to make both upper 4 links compliant in this case which seemed to work fairly well. The resulting formulation isn’t super classy from a numerical point of view, but does seem to be stable and solve times are sufficiently quick (roughly 8 seconds of integration time for a 12 seconds of simulation time). Here’s a pic of the resulting rear suspension:
From an experiment perspective, here’s what was created:
Experiments created for the drag car project.
The setup model can be used to adjust ride heights / preload on springs / weight distribution. It’s essentially mimicking the mechanics ‘setting up’ the car. The results of this ‘Setup’ simulation are then applied to the ‘******_settled’ simulations.
The MassCheck experiments are simply used to validate that ALL of the adjustments are being extracted from the ‘Setup’ simulation and properly applied to the vehicle for the subsequent simulations. If everything is done properly, the vehicle will remain static from initialization through the end of this experiment. If the vehicle bounces around at all it means that the developer has made a mistake somewhere along the way!
The most interesting (or FUN) experiments are the “Launch” experiments. These experiments essentially make a pass on a 1/4 mile drag strip. At the beginning of this simulation, the car is given a bit of time similar to ‘staging’; the RPMs are increased and the car is launched and runs at wide open throttle down the dragstrip.
At the end of the simulation, the time slip is generated in the sim log to see how the digital twin of the drag car performed. In this case, it ran the quarter mile in 9.747 seconds. But the question is, what part of the simulation is awry, as the 60ft time is terrible! I’m told you’d generally expect a 60 ft time of more like 1.3 seconds. I suspect it has something to do with how the vehicle is leaving the start line, and probably that my lower 4 bars end up pointing a bit downwards (evident by the green arrows in the image above). But, who knows for sure!?
The digital twin timeslip
In closing, this model is far from perfect and certainly needs a bit of critiquing / calibration but creating this set of simulation models was quite enjoyable. With that said, I suspect it was nowhere near as fun as racing the digital twin’s physical counterpart!
Anyway, I hope you enjoyed reading about this process as much as I did building the simulations. I also hope this overview of my thought process along the way is helpful in some way / shape / form for you. If you are interested in running some simulations on a drag car, or have any questions about how we achieved any of this, please reach out to us at email@example.com.
Nate Horn – Vice President
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion.