Last edited by Big Bird; 01-25-2016 at 03:40 PM.
RMIT FSAE 02-04
Monash FSAE 05
RMIT FSAE 06-07
Design it. Build it. Break it.
a very thought-provoking post, good work
I think breaking the project up into the 4 levels is a useful way of breaking up the tasks and objectives of the team, as I read it occurred to me that a very simple and probably quite effective way of defining the roles of people within a team would be to assign their responsibilities to a level. Using the management structure our team uses, you would have:
Level 1 - General team members
Level 2 - Subgroup leaders
Level 3 - Chief Engineer
Level 4 - Team Leader
And typically the goals for each level are set by the person responsible for the level above, e.g. subgroup leaders give team members briefs/instructions for component designs to help them achieve level 2 goals, chief engineer gives subgroup leaders performance targets to help level 3 goals be met and so on.
As I'm approaching the end of my final year in FSAE, I certainly wish I'd spent more time to get out of level 1 and 2 and put some good analysis into level 3. I guess the interesting thing here though, is that while spending time on the analysis of level 3 aspects of the design has the possibility of being very fruitful in terms of competition success, it's the details in level 1 which can make or break a competition, as the detail design will really be what dictates whether the car is capable of achieving any of the higher level goals, and obviously whether something fails in the middle of endurance - so it's not suprising that most teams will devote considerably greater effort to the lower levels. edit: although more high-level analysis would undoubtedly reduce the workload and add direction to the lower levels
University of Auckland '06-'09
Kudos to Geoff!!
I think we've all been waiting a few years for this post!
I'm glad to finally see someone with some a wealth of experience sit down and write a fairly definitive (although i'm sure Geoff will protest otherwise!) top down explanation of how to do this project.
It's great for new teams and also really good for established teams to take a step back and have a good look at whether or not what they're currently doing is helping their cause.
I hope the mods sticky this one as I think it will alleviate a lot of the simple questions which seem to have been plaguing the forum recently.
Thanks again Big Bird.
University of Glasgow BEng 2003-2007
Oxford Brookes MSc 2007-2008
University of Glasgow PhD 2009 - god knows when.....
Preliminary operational tests proved inconclusive.... It blew up when we flipped the switch
That's excellent stuff, Geoff. Everyone should read that.
I totally agree, and think a particular note of importance is that design should be driven from 4 to 1, not 1 to 4.
IMO, 1 to 4 is "tinkering" whereas 4 to 1 is "engineering."
To save time you can certainly work on Levels 1, 2, and 3 simultaneously. The key though is that the high levels drive the lower ones, not the other way around. Using my Formula 1000 project as an example, I have spent a fair amount of up-front time on "Level 1" design, but in a manner that's easily configurable. I can have a rough idea of where A-arms, rockers, and dampers are going to fit and go together.. and once I determine my upper-level targets I can change a few sketches and the L1 components re-build themselves as necessary. You don't need to worry about what A-arm planes and specific hardpoints need to be.. when you define upper-level parameters they all fall into place as the only unique solution.
In my experience while doing this stuff, as talented as we thought we were, we barely had enough experience to really grasp the Level 1 part of things. Only a very few people really had any knowledge of REAL materials selection and manufacturing.. or stuff like the experience to avoid bare aluminum suspension spacers as they have the tendency to warp and gall and stick. Likewise there was always a learning curve regarding all the suspension and engine terminology, much less having in-depth real understanding of tire/vehicle dynamics.
As such we fumbled around at the 1-2 level, organized by a leader ("captain") who was taking their first stab at project management and inevitably wound up biting off more than they could chew. I readily admit I was no exception.
Given that most engineering curricula are geared toward developing a "Level 1" engineer, it is difficult to truly orchestrate a diverse, talented team that operates on all levels. At least from CU it would have been nice to have courses in systems engineering and management. I'd imagine the way to really develop people beyond the 1st Level in FSAE is to have lots of engagement at the underclass level, and work very hard on knowledge retention. Otherwise you're starting all over from scratch every year.
The other point you make that I really strongly believe in is to separate the high-level design drivers from the low-level details, at least initially. Start simple. I really like the example of building a simple lap sim that uses only peak acceleration values. Forget all the other crap initially. Once there's some comfort level with the basics, start moving incrementally toward more detail.
Overall a very good and well-written thread.
Colorado FSAE | '05 - '07
Goodyear Tire & Rubber | '07 - '11
NASCAR Engineer | '11 - ??
I know I've been waiting years for someone to put some kind of number on points/kg.Originally posted by Big Bird:
The greatest lesson I learnt by working through the above process is how little effect the potential performance of a design really plays out on final results. For example, my own model indicates that a 1kg weight saving is worth around 1 point in the overall event. If we can see that for instance, a 5kg saving is worth maybe 5-10 points in terms of overall potential - and then we see that the top 5 in a comp may be spread by 200 to 300 points – it puts perspective on all that time you spend saving 1kg out of your chassis or a few hundred grams out of your uprights. And that if your team ended up 250 points behind the winner, or even 50 points behind the winner, it is not going to be a change in your vehicle’s performance specs that is going to bridge the gap.
Your post is what I'd call System Engineering. It is a master program at Cornell and the team works much the same way. We mostly look at the points system first and determine sensitive areas. In general we're looking for more power/less weight, but how we achieve those goals is often driven by a systems approach where we try to determine ahead of time our "biggest bang for the buck".
Project management is one of the most important areas for success because it's very easy to waste man-hours on things that don't contribute to the overall goals. And due to the limited number of man-hours all projects are prioritized.
Unlike Malcolms team we don't however have a chief engineer or single team leader. It stops at level 3 with a team committee of sorts. There is typically a team leader for each of the following; chassis, engine, electronics, and business. This is usually driven from the fact that no one person can be responsible for everything, nor is an expert in every system. It also means there is a specialist in each area present when hard team decisions are made. We do have subteams (and subteam leaders) in both chassis and engine, which report to the team leader in their area. The car is broken down to just about every last component, and team members are made responsible for those components. Subteam leaders need to know everything going on in the subteam so that at least two people are experts on every part. That way if someone can't be reached when there is a problem, someone else can be contacted. For some stuff this never is a problem, but for some electronics stuff there really may only be 2 people capable of troubleshooting.
I think not enough man-hours, and weight has been aimed at final tuning of the car in the past. With the tire consortium, I bet that this has been improved overall, but a lot of teams worry about every last hp when designing intake and exhaust systems, and then throw it way with a bad engine tune. Likewise on the chassis, our team struggled one year in doing simple toe, camber, and tire pressure matrices that are critical in taking full advantage of the tires. It's a lot easier to throw away 50 points then it is to find 50 in design.
'engine and turbo guy'
I agree here with everyone - I think that this should be nearly mandatory reading for anyone joining a team, and especially for those taking on any sort of leadership roll. While none of the thoughts are necessarily earth shattering, why its great is that its in a great, simple structure which helps drive home the point. We can debate all day over the individual points, or how its broken out, but the main message gets through very well - and really makes it a valuable read (just like the rest of your posts).
The hard part for teams, even that agree and want to follow this path, will be working this in to understand how to best manage all of the forces pushing them towards just doing what is easy in the momemt (#1) and the benefits of avoiding taking that path.
For instance - everyone knows that as much testing and prep as possible will certainly help with competition performance. So in response, with an eye towards getting the build moving, teams say "ok lets start designing and building as soon as possible". They then run off in 5 directions to get going by delegating work (if possible).
For many small teams, the core group of 2-3 probably feels it necessity to spend as much time "working" on designs/building as possible, rather than thinking about how to best prioritize and where the extra time spent by the best people on the team will yield the best results.
This is why some very small teams can do surprisingly well.. if you are just that short on man-power, you have to make these decisions, and spend a little bit of time thinking where can I spend time, and where do I have to just do something quick and dirty (or just buy it). At the same time, these teams will have 1-2 people doing all of the design so there is automatically a more holistic view of things.
Unlike a normal corporate environment, the people on the team taking the lead roles will also be doing a bulk of the work. Finding the time to really step back and spend a few hours at the start of every year/month/etc to plan and prioritize, in the same way as any compay does when it projects the next quarter's earnings, etc, and which divisions will provide that $, is something that really can be invaluable, and something that I can say I certainly didn't do enough of in my time. Having good direction at the lower levels of a group, makes doing work much faster/easier, as you aren't trying to think about what your boss/group lead is thinking about - but instead can focus on executing. We have all designed many quick parts standing at a mill, and it took no thought, because it was just a matter of already having all the main constraints set - and being able to do as much of that from the start of the project makes integration and moving forward with everything probably that much easier and faster
Excellent post Geoff.
Just one thing I'd like to expand on:
In between Level 1 and Level 2 is what I believe to be the single most effective way to build a good racecar: minimising the parts count. Parts you don't have weigh nothing and cost nothing and cannot break.
I'm not suggesting another level to the Systems Engineering approach but it's important when cascading out the design from Level 2 to Level 1 that you don't have too many parallel paths.
I don't have much time to discuss further today but I wanted to get the comment in ASAP. I have in the back of my mind a 'thesis' on the Minimal Parts Count Racecar. One day I'll have the time to write it.
Thank you for that post Geoff.
Hopefully it will be 'stickied' for all new teams to find easily.
PS, I emailed you at your RMIT address earlier today.
The trick is ... There is no trick!
Geoff, thank you for that post. Trust me when I say I'll be doing a lot of thinking about that this week (when I should be studying for two midterms haha).
Having read it, I can say there are some higher level things I already do/do automatically, and some that I never really thought about. Your post will help me figure out how to fill in the gaps. Being good friends with both of our past chief engineers (one graduated) has certainly helped. The way we are structured is:
-System Heads (including a new system, sponsorship/fundraising)
-Chief Engineer and President (CE being in charge of design, president in charge of administration, although both of us being MECE juniors means that we do a lot of consulting, and he is chassis lead)
We have traditionally been a "small" team, with usually 10-15 solid members at any point in the year, but this year we grew quite a bit, and I can say that going from being the only engine guy to being trusted with heading the entire design (now with, say, 20-25 solid members, many freshman) is almost overwhelming. I already have some clear ideas of how I would do things differently, given a second chance at this (I DO have another chance, if the team wants me to be chief engineer again next year). We are having to make compromises at this stage that I was hoping to avoid, but the project must move on.
I hope this gets stickied, it is probably the single most valuable post on these forums (of what I've managed to read so far).
Thanks for the post Geoff. It was a good read and I have to agree with you on many of your major points.
The only thing I would add is...have fun!
John "Jack" Vinella
University of Washington Alumni 06' 07' 08' 09'