Conceptual design stage tools and methodologies

Hello! I am Vishnu Sanjay and until I recently graduated, I was the mechanical lead at the FSE team, 4ze Racing, of SRM University, Chennai. With Formula Student Germany 2017 recently concluded and with my team looking to compete at next year’s edition of the competition, I thought I could help out a bit by starting a discussion regarding the conceptual design stage on these forums.

A word of warning; this post contains about 3000 words and might put you to sleep if you attempt to read it in one go.

Anyways, now that I have mentioned the possibility of that happening, the key reasons for me deciding to do this are twofold, and neither of them is my interest in developing a textual soporific. They actually are:
1. I spent a lot of time thinking about stuff after seeing them debated on these forums. The facts that there were multiple viewpoints presented in discussions, and that I didn’t have a way of knowing which arguments were right, were what spurred me to explore fields of study that I had a poor understanding of prior to coming across that discussion. This then led me to understand and develop tools and systems that enabled me to verify for myself, from first principles, which of the viewpoints presented had possible merit, and with what assumptions they did so. This is how I was able to start thinking in terms of the system instead of just in terms of the parts. It was by this method that I was able to guide and convince my juniors to devote their time and efforts towards understanding certain aspects of the car and project that I deemed necessary. HOWEVER, it was not always possible for me to convey what assumptions I was making when I told them something, and so if they accepted what I was saying without thinking them through, they could easily, in the future, end up misusing what I said. They are not necessarily to blame, as it requires being at a certain vantage point, before being able to see most system level issues clearly. On these forums however, there are people who will definitely be able to tell me if I missed out something important, that they should be aware of.
2. In Geoff Pearson’s (Big Bird’s) excellent ‘Reasoning…’ thread, he subdivides the project into 4 levels. Most of the damage to the project is done when people ‘blindly follow’ other teams when making any decisions at Level 1, without themselves deriving them from whatever their own higher level capabilities are. Now, during my time at college, during my final year, I understood the necessity for better project management and systems engineering in my team and was fortunate enough to meet and get a like-minded faculty member at my University to hold a few Project Management sessions and classes on Control Systems with the team. More than all else I did, this was, in my opinion, the biggest contribution I made to my team. The current team is definitely better equipped than mine was, when starting out with this project. Very briefly, their Level 4 and some of their Level 3 goals have been defined, with the car to be designed completely by December, and the car running by March. All the consequent implications get flowed down to Level 2 and Level 1 goals. Now it is with respect to Level 2 (Vehicle Integration, which is what a conceptual design stage occupies itself with) that I hope most of this thread will devote itself to. I do have some ideas regarding these and the current team leads are aware of them. However I would really like to hear how other people would do it too.

THE CURRENT SITUATION:

Now, before I proceed further, I would like to state that most of what I say from now on is aimed at a team like my juniors (a team that understands/must satisfy the following before getting into any of this: reliability is key, rule compliance is key, low cost is key (no top team budget) and a car for FSG needs to be done by March). They have about 15-20 students who were recruited just prior to our build, with about half of them being more equal in my eyes than the rest. They also have about a dozen new recruits, who will spend this year getting up to speed. The budget for my batch’s project was around $17000 overall for the entire project, including costs for the competition, and they are not likely to get significantly more this time around, due to the many other projects that the University also funds. The fact that we won our National Competition (more because we had a more-reliable-than-the-rest car than because it was fast) might get us slightly more, and hopefully attracts support from a few more sponsors during the course of this season. They have spent the time since the competition ended testing the car and figuring out in what ways and why the car did not deliver what design predicted. I have been helping them process and interpret this data,(I have posted some of it on Bill Cobb’s ‘Testing…’ thread) and together we have found how much compliance and poor attention to manufacturing detail contribute to a disappointing track car.

However, I don’t intend to keep complaining about the car. Testing it was a very useful what-not-to-do lesson to everyone involved and will have significant impacts in the way the next car is designed. I shall continue describing in what other ways they might face constraints. A major manufacturing constraint due to a limited budget was: My batch wasn’t allowed to operate the CNC machines in our CNC lab (we have operators) and this significantly drove up production time. The Hybrid team found a clever way around this by writing all their CNC code before they showed up to machine their stuff, and spent only about half the time we did. Nevertheless, not being allowed to operate the machines yourselves could be a disadvantage (the CNC lab closes at 5 every evening). It forces the team to be better organised, and to rely less on machining, if they want to get stuff done. The more organised a team already is, and the more ways it knows to make strong parts quickly (hint: sheet metal fabrication and welding) the better equipped it is to make light of this. It also makes it critical for a design freeze to happen before December. Now, allowing for at least a month for a detail design stage, this only leaves them two and a half months to explore the design space. It is this that I would like to make easier for them with the help of this thread.

Of course, you guys could share stuff that has worked for you under different constraints. I for one would be very interested to hear about them, and it might tell my current team which constraints to try to eliminate for future batches.

Right now, the things that they have going for them that I didn’t are: an understanding of testing of a car, test data from a car, an understanding of control systems and improved project management (means there are still the usual annoying ego clashes, and some lazy individuals, but most of the guys who want to contribute have their heads screwed on somewhat better than I did). But, and this is where I’m trying to help, they do not yet have the kind of clear communication between subsystems and are (so far) still slightly sketchy in their understanding regarding what tools enable this to happen.

Also, another thing that I have only recently realised in a conversation with a friend was that viewpoint transfer is just as important as knowledge transfer in a project like this. Unless this is done, it is likely that people will do things because someone in the know said so. This kind of stuff is level 4 and since a competition rarely asks for such documents, such documents are rarely prepared. Funnily enough, our National comp required of us two things that an international FS comp doesn’t. One was a Gantt chart, and the other is that our car needs (certain parts) to be assembled and disassembled within an hour. They were both useful. And also, when explaining our Gantt chart, and helping my juniors make theirs, a lot of the project’s quirks and potential pitfalls became apparent to them. They now currently understand that managing the project is more important than and at least as difficult as the Level 1 work they had been mostly spending time on previously.

[Character limit, continued in the next post]...

.....[Continuation of above post]

MY VIEWPOINT, THE ONE THAT I HAVE SPENT TIME TRYING TO TRANSFER:

Alright, so now that we’ve got that out of the way, back to the matter at hand. Our team has around six key technical subsystems:
• Tires and vehicle dynamics, and now aerodynamics (first time in the team)
• Suspension and steering
• Chassis
• Wheel assembly and brakes
• Powertrain (Batteries, motor, controller and drivetrain)
• Electronics.

As mechanical lead, what seemed to be very apparent was that an understanding of dynamics was what was chiefly required in order to do well at a competition. Don’t get me wrong, each of the subsystems is difficult and requires a lot of good engineering to make the package perform as intended on race day, but understanding vehicle dynamics, more than any other field of study is what I think will help a team improve at the competition. You could make the case that there is no vehicle dynamics without the other subsystems, and that would be true, but since all the other subsystems have other issues to concern themselves with (how to achieve W stiffness/mass requirement, how to provide X power in Y manner, etc.), it is useful to have one domain deal with this in abstract terms and flow that down into requirements for the other domains. Now, at our team so far, we have found it useful to have both. A few members in each subsystem also contribute work to the vehicle dynamics subsystem. This is so they understand where their domain starts, and what requirements it starts with. The benefits of this are avoidance of issues like (suspension requires X dampers to be better than last year’s suspension, and better individual subsystems mean better overall car). The drawbacks of this are, yes, their time has to be divided between their own subsystem and the dynamics. So far we have had no issues. This of course might change based on the members in the team during one particular year. From next year on, the team that designs will have on it members that have two projects worth of experience, and so should, I think, be able to handle it well. (Yes, we recruited two batches worth of recruits, and the young ‘uns are motivated AND have made great progress, hopefully they stay on till they graduate).

As mechanical lead I also deplored answers being handed to me like ‘the sim says so’ by people who did not know anything about why the sim did do, and whether their inputs were realistic and their outputs verifiable. Consequently, when I asked my juniors to read something, I would first recommend a general book on an actual field of engineering BEFORE recommending something like ‘Fast Cars made EZ’. This is because I have not read many books of the latter type that explain to me how things work from first principles. I know some here feel that this is a long and circuitous road, and the project does not have sufficient time for people to follow this approach, but unless I am working under a chief engineer who is very experienced with a shortcut tool who could catch any mistakes that I make, I will not be using it. The same advice would go to a chief engineer. If you are relying on information that neither you nor your informant can stand behind, you already playing with fire. A good project with a low risk on delivery does this as few times as possible and takes steps from future versions of the project from being in such a position.

So, breaking down just the mechanical subsystems into special cases of certain fields of study in mechanical engineering (Happy chief engineer should have a decent understanding of all these and your parts will be not be likely to fail if you check that your ‘assumptions’ are being met at each stage. Else, he will have to resort to an Izod test involving you if your part fails and you explain reality is wrong and your EZ software never lies).
• Vehicle dynamics – classical mechanics, and the different methods used for solving them. I personally have seen Z explain a lot using just Newtonian mechanics; Doug Milliken and Claude seem to use the methods in RCVD more, which relies on Aeronautical handling and controls, and Bill Cobb shows methods on these forums of how to use Control Systems methods. All of these methods, are however, based on the same laws of classical mechanics, and even though I now enjoy comparing the different methods, and using them in different cases, I currently lean more towards Bill’s approach. I note though, that this is just for me, and at times like Z says ‘I get lost in the alphabet soup’ and how many people find the RCVD approach very useful. What would also be useful is some data analysis and programming skills that will help during tire data analysis, and test data processing. It is also great if you have the entire Control Systems skillset (System Identification, System Analysis and System design) which is what the top teams currently need, to implement their active control systems.
• Aerodynamics- Some understanding of general Fluid mechanics and Aerodynamics, before getting stuck in CFD sims.
• Suspension and steering- classical mechanics applied to machines i.e., theory of machines, (Z has spoken of Screw theory, but most software is based on computational spatial mechanics, along the lines of what robotics teams develop-a new thread on the forum seems to show an Egyptian team doing this), multi body dynamics (math modelling courses deal with this).
• Structural stuff (Chassis, wheel assembly, drivetrain and the suspension and steering as well)- Strength of materials a.k.a solid mechanics, materials science, manufacturing technology, machine and transmission elements design).

WHY IS SUCH A VIEWPOINT USEFUL?

By no means extensive, but I hope you get the idea. Most of it involves fields of study usually taught in a Mechanical Engineering course. Of course, none of this might be taught well or the way it should be at your University, but it is by no means impossible to learn them as a team. Doing so really does enable the mechanical team to speak the same language as much as possible. The team is also less likely to fool themselves into thinking along the lines of: ‘Just carbon fibre is what makes the fast teams fast. We need CFRP too’. I think anybody who has spent enough time on these forums will know that it is not funny the number of times daft ideas like that get taken seriously and lead to expensive boxes with wheels.

Anyways, with this base, and maybe a few more subjects that I have missed, I think it is possible for a team to understand a car from first principles, and definitely with some understanding of programming and applied mathematics, understand most of the software packages that usually are used at the design stage. I find that writing basic code, not as extensive as commercial code, definitely cements understanding and can be used as a useful verifier of whether expected trends are seen in more advanced simulations. This is similar to anticipating results, and verifying whether obtained results make sense when using a simulation.

What gets my goat is when nobody in the team understands what a simulation or software is doing or whether it is being used right (yes, even with home grown simulation I have been fooled) and still decide to take it further in deciding critical vehicle parameters.

Now I have seen this sort of bad practice done for all subsystems:
• Vehicle dynamics – Stuff like CarSim, CarMaker, ADAMS, VI sim-all seem great, but I know that if I received today a result from one of my juniors using any of these, I would not be accepting it at face value. All these software to some extent or the other tell you how your vehicle performs on a given road.
Personally, I find smaller dynamic simulations and calculations of the kind that RCVD, Z and Bill Cobb have suggested to be a first step and only after a somewhat clear understanding of what I’m getting into would I be open to others which introduce variables which I am not sure of.
• Aerodynamics-CFD without knowing why, and what for, and for what targets.
• Lapsims, without knowing whether configurations are realistic, can be handled by a driver, or just plainly wrongly written.
• Structural- FEA. As a wheel assembly engineer during my second year, this one is close to the heart. I was presented a colourful picture that said the broken hub I held I my hand was not possible. I picked up Timoshenko from my library sometime that week. Now however, I am able to understand more about 3D boundary value problems and am learning how to use the finite element method to help me, not to do for me while I press ‘Run Sim’ (=’Don’t run car’)
• Suspension kinematics and steering kinematics solvers.

Now as a reminder, I have no problem using these software. I only have a problem when people who don’t know how to use them do so. Also, additionally I will concede that first year teams could have a time constraint that prevents them from doing even this. I think they should realise that their situation is not a good one and take steps to at least change the setup they have for the people they recruit. I have also seen evidence on the MATLAB and SIMULINK racing lounge of top teams modelling their own in Simscape, especially for Lapsims, and the understanding this entails seems to be working for them.

[More coming, character limit again...]

[Continuation of my two previous posts...]

Now, that’s the kind of mentality that I have been moderately successfully in establishing in my juniors. What I think they should be doing with it for these next two and a half months:

• For the next month, I would figure out: what vehicle parameters contribute to the car’s performance. See if such parameter values can be manifested as some form of hardware, based on their abilities as engineers. I would also finish my analysis of this year’s competition’s performance to see in what range my ultimate vehicle performance needs to be. At the end of this I will have an extensive list of what my system requirements are.
• Once a few physical equivalents are identified, (and even fewer parameter permutations I think) check them all out to see which ones match the project’s abilities (cost, time to make,etc.) and run them in realistic lapsims like the Virtual Formula and see if they perform sufficiently well to achieve the project’s goals. There have been many interesting ideas that I have read about in these forums, and have shared with them, that I would love to see evaluated in such a fashion.
• I think most of the tools that Bill Cobb has posted here on these forums and on the TTC forums, taken to complement the MMM diagrams we generated last year and a lot of posts by Z, Claude, Bill, Pat, Doug, Geoff, Tim Wright, Kevin Hayward and folks like them on these forums are sufficient to do this. What tools get the information to my juniors quickly is what I am interested in.

THE BIG QUESTION:

Enough for one post is what my word count tells me. Is this (running these different sims simultaneously until all the system requirements are satisfied) how you would do it if you were/ are running a team? If no, what would you not do/ do differently/add to/ subtract from the methodologies and simulation tools I have spoken of?

It is this that I still have some trouble in explaining clearly, it seems like everybody in the team would be going back and forth all the time to find these configurations, (it’s easier in my head than I expect it will be for them) do you guys have a suggestion for a methodology that maybe has worked for you?

I truly respect those of you who have made it this far. I apologise for the length of this pot, but hopefully it yields something useful.

Also, any thoughts, criticism and affirmation of any/all I’ve said above? I’d really like to hear what I could have done better, and where I might have gotten them barking up the wrong tree.

Cheers,
Vishnu Sanjay.

Vishnu,

I will sure give you some comments in the next few days. Your questions are relevant but to put things into perspective, could you briefly explain what your team history and performance in Indian and possibly abroad competitions are?

Claude,

Thanks! I look forward to hearing what you have to say.

My team has been around since 2012. We’ve produced two cars for competition since then.

The first car travelled to FS Italy in 2015 and spent the comp watching from the pits. It failed to clear scrutineering because we had HV wires leading out from our sidepods before entering the rear section of the car (Not within the chassis envelope). It weighed 320 kilos without a driver; most of its mechanical systems had been designed by a single person (from what I’ve been told), who couldn’t make it to comp and it took slightly more than two years from design to event. I got to understand a lot of stuff at the comp through discussions with the other teams, especially from Petr Suchacek of EForce Prague who we shared a pit with. We also learnt a ton from the officials, (Tim Wright was one of them) who were nice enough to give us a thorough mock scrutineering, even after we had been deemed unsafe for the track.

Lead up to Italy: Stuff that we were asked to read back in September 2014, were along the lines of Pat’s Corner and Tune to Win only. At the time, these, and whatever they had absorbed from class were the only resources they used to design the car.

We were visited by the FSE team from Vellore, Ojas Racing, early in 2015 and it was from them we first heard about RCVD. They told us they used it during their design stage. Within the fortnight, we had three people from my batch reading this.

Car 2:

By the time Italy had finished we had finished reading through the first half of the book. By November we had MMMs plotted (the other two guys who had also been reading RCVD with me wrote most of the code, with just weight transfer effects at first and this was expanded later to include TLLTD (one of them was a suspension guy) and was also used when designing the steering (the other being in charge of steering) I sadly did not perform the structural guy’s role of including compliance in it at the time).

Our conceptual design stage went something like this: Selected a tire, get a tentative packaging concept, evaluated performance of base model on an MMM, designed geometry to suit, structural design around it (we only concentrated on stiffening some of the ‘springs’ while leaving others soft, I admit). We allowed a lot of things to progress too far before correcting them(our driveshafts were packaged at something like 26 degrees and we spotted it about a fortnight before our proposed design freeze), and this ended up delaying the process.

December saw the project face its first flood. The next semester saw us finish design. Manufacturing took another semester. We lost seniors to company placements and final year projects. December saw us finish manufacturing and we faced the second flooding of our lab (I’m not joking, we did really have our lab flooded twice, each December, by cyclonic rainfall in the region that lasted weeks – at one point we debated building a boat instead). By now, our chief priority had returned to reliability (we admittedly did lose sight of this amidst all the chaos) , and the fact that we designed for low cost fortunately meant we had cash left over for spares, when a motor unexpectedly failed, and when powertrain components fractured. By the end of March, we were somewhat well tested and seemed to show it compared to the competition, at Formula Green, organised by ISNEE. (We don’t yet have an electric category at FS India) .Four of the nine teams that competed had, I think, previous FS experience. Sadly, they still had certain issues with their cars or logistics and could not do much, as we ended up winning by close to 600 points. Full disclosure: However, the gap does not reflect the luck that we also had on our side, because after three or four test sessions after the competition, we did suffer another component failure within our gearbox. Another part that had evaded inspection or testing before being put in the car.

We’ve spent the time since the competition testing the car and figuring out which of our other design assumptions and manufacturing practices were silly. And we have found quite a few.

In a nutshell, that’s pretty much it. I’m sure most other FS teams would have had similar scenes at some point in their history.

Back to the conceptual design stage:
I think sure, it’s nice to have a methodology, but it will not work unless you have the engineers capable of designing what the systems require. This has been an issue previously where even though you know what is good for the car, you get engineers who don’t know how to achieve that except for a very high mass or a very high cost (by basically making a bad tradeoff decision that ends up making things worse overall).It is for this reason that I have been creating a library within the team of the useful threads on this forum that deal with the prior art (Like the suspension design thread, the steering with pitman arm thread, and suchlike) so that this coupled with their understanding of the mechanical engineering fields that I had spoken of earlier, should help them to be less hasty before saying that good values for crucial vehicle dynamics parameters are impossible to achieve unless we do it using the exact physical solution that the other teams are using. If this keeps happening for enough years, and the team’s design reports all say the same untruths, it becomes more and more difficult to break out of the rut, in my opinion.

It is because the vehicle level integration and understanding that a team does/has at this stage ends up affecting all the processes that come after it, that I would like to hear what other people have used successfully or unsuccessfully at this stage. A lot of my learning has come from the mistakes that other people have made in this project (and that they have been nice enough to share here), and the mistakes that they have made at this stage they don’t seem to have been posted a lot yet, so I’m hoping I get a few responses now.

Cheers!

That is what I was fearing. I admire your passion for vehicle dynamics but RCVD kind of book book (as good it is) is not the kind of book you need to read for now. RCVD and other such book will not help you to pass technical inspection, noise, tilt and braking. It probably won't help you to gain reliability.

How good is it for you to simulate you car behavior if to start with your car does not pass technical inspection.

I am afraid you did fall in the typical academic Indian educational system that values academic knowledge and do not rewards end result of manufacturing and on-track performance.

For the moment you need to acquire good sounds basic design engineering principles and discipline.

More to come when I will have found a bit more time.

Vishnu,

I hope your team will attend Formula Bharat (whether as competitors or just spectators) in January at Kari Speedway in Coimbatore.

I have a presentation aimed at exactly what Claude has pointed out is missing!

To build a house, you must first dig the foundations. FS is no different!

Pat

Claude and Pat,

Thank you for that. As I mentioned in my first post, what you say is already playing a part in the project. And I did not mean in a 'pure;y academic' way. I also think I should point out that the competition ended four and a half months ago and since then we have been testing and understanding the importance of what you have said for ourselves.

That was entirely the sentiment behind my first post, it deals with acquisition of 'basic design engineering principles'. As for practice, from what you two have said, I guess that should be what we take care of before taking on anything else. Got it, will do.

I'd be interested in anything you have to add to this.

Vishnu,

I suggest you attend the 4 day OptimumG seminar that I will be teaching in Coimbatore from January 29th to February 1st 2018, right after Formula Bharat.

You will have both Vehicle Dynamics and car concept, simulation, design, manufacturing, testing advice but also some good guidance on team building.

Claude