+ Reply to Thread
Page 1 of 19 1 2 3 11 ... LastLast
Results 1 to 10 of 183

Thread: Reasoning your way through the FSAE design process

  1. #1
    Senior Member
    Join Date
    Jun 2003
    Melbourne Australia
    Greetings all,

    I’ve been sitting down in the odd spare minutes I’m getting here and there, and slapping together a bit of a thesis about what I think of design, specifically in the FSAE context. I’ve written the odd wordy response here and there on these boards, but as with the nature of these forums they tend to get scattered in the morass of information. I figured I’d slap it all together in one place and see if it sinks or swims. Over the next few weeks or so I’m going to slap up a few different pieces relating to FSAE. It will be mainly to do with the philosophical side of the event, given there is a wealth of information here relating to technical design issues.

    The following is around 4000 words or so. It might be rather painful at one sit, so you might want a beer or two to see you through.

    My contention has always been that this even is won and lost on good management principles. Unfortunately we are not taught such things in our university careers. Rather we are mostly taught a collection of quite disparate facts relating to engineering science – and it is up to us to piece them together into some sort of greater truth. Therefore many of us blindly barge in with our bag full of engineering formulae and software skills, and attack an engineering design problem the way it is taught at uni. Given the repeated failure rates (usually around 60-70% fail to complete all events at most comps), and the large disparity in points across the top 10 at most events, I think that what we have been taught is falling short to some extent. This competition isn’t anywhere near as close as I think it could be or should be.

    Whilst many of those attempting this project have excellent technical and analysis skills, something is getting lost between the design stage and the implementation stage. We are often seeing engineering as a purely technical exercise, whereas in a real project we have to take in a lot of outside factors that can conflict with, or even overwhelm, our technical aims.

    The key point is that we have finite resources, and this is true of all project situations. Sure, in F1 the limit of those finite resources is somewhere up in the stratosphere compared to what we have to deal with, but even at that level the resources aren’t infinite. And when you are dealing with a finite resource base, then your design decision making process needs to reflect those limits. Not only do you have do decide whether a certain component or design will make your vehicle faster (if that is your design goal, but more on that later), but you also have to assess whether it is the most feasible direction for your team to find car speed

    So rather than just say that “this is all about management” and leave it that, I’m going to try to put my money where my mouth is and convey what I consider to be good holistic design principles. I don’t consider myself to be a guru of any sorts when it comes to such things, but after viewing around a dozen of these events I feel I have seen enough common failure points to at least offer my thoughts. At least once I have committed all this stuff to screen, I might feel as though I’ve said enough and won’t have to bore you all senseless by hijacking your threads in future.

    Design Management Structure
    The following is a bit of a structure I’d follow as an FSAE vehicle design process. You’ll note that the thread I’m presenting below is focussed on the actual vehicle design itself, since that is what we talk about most in FSAE circles. Once you have read through it you might recognize that we could generate similar trains of process for the static events, and these would link in at the top end of the process. But I’m getting ahead of myself.

    For the sake of readability I’ve labelled the below Levels 1 to 4, although this does not imply any order of importance – they are all significant in their own right. You might think of them as a design hierarchy, but I’d say each level has its own type of expertise required to make a success of this project.

    Level 1

    This comprises design and manufacture of the individual vehicle components, and this is the level we are probably most comfortable with after our university training. This is the level where we are designing parts, calculating loads, masses, stresses, stiffnesses, heat transfer rates, etc. We are using typical engineering design and analysis tools such as CAD, FEA & CFD software, maybe engineering formulae, (stresses in shafts, bearing loads), etc. It is probably the area where we can best get advice from our academics, given this level requires expertise in specific areas, and generally academics tend to be people with deep expertise in a particular field.
    Types of questions asked at this level: How do I make this part lighter? How do I make this stiffer? What material will we use? How do we manufacture this component? What physical tests do we need to perform on these components? Do we want a magnetic or Hall effect sensor for our crank angle sensor? What spring stiffnesses do we need?

    Level 2

    This is where we are joining all the components together into a complete functioning vehicle. It is also the level where we identify conflicting goals that may arise between different components and sub-systems.
    Types of questions asked at this level: What are our performance trade-offs at a whole vehicle level? How does our suspension geometry match up with our differential choice? How does our engine packaging tie in with our need for easy access and servicing? How do we address tradeoffs between engine mass and output torque/power? How do we address the conflicting demands of cockpit packaging and front suspension geometry?

    Level 3

    Given the whole vehicle at level 2, how does this design tie in with our overall competition strategy.
    Types of questions asked at this level: How do we score the greatest number of points at competition? What are the inherent trade-offs in our own design at event level? For example, how does our vehicle speed strategy tie in with fuel economy? Are there conflicts between our dynamic event performance and our static event performance? What are the risk factors that could possibly jeopardize our competition performance?

    Level 4

    This is the over-arching management of the whole project – how the competition performance ties in with other managerial level stuff like time and budget management, usage of human resources, etc. Functions performed at this level: Holding the whole project together so that you deliver this year, keep everyone reasonably happy, and hand over a healthy project to future teams
    Types of questions asked at this level: What are our goals for this project? Are they feasible given our resources? How are we going for budget, time, material resources, etc? Are our key stakeholders (e.g university, tech workshop staff, sponsors, supporters, team members etc) happy with our project? How will our project affect future teams? Are our team members working in harmony? Are we leaving this team in a better state than we found it?

    Discussion of above process
    There is nothing particularly ground-breaking about any of the above, and I hope I haven’t trivialized all this or bored you with statements of the obvious. However I personally think it is really important to break down this complex project into its constituent parts, and know how where each sub-problem ties into the project as a whole. Being part of the leadership group in our team years ago, we were faced with all manner of issues to deal with: budget and time management issues, workshop access, setting performance goals, design queries about individual components, packaging conflicts, tooling purchases etc etc etc. We certainly couldn’t solve these problems and make decisions without knowing where to file them and how they all linked into each other in the overall heirarchy.

    I’ve made a few simplifications with the above process. Most notably, you could easily split up Levels 1 and 2 even further, into components integrating into sub-systems then integrating into the full vehicle. That is up to the individual, but probably not too relevant to my following argument.

    I won’t bore you with too much analysis of Level 1 component design, as there are plenty of books out there on vehicle technical design. We should all be reasonably aware of what goes on here, our universities tend to focus on this for our engineering training and most of us should know how to use engineering software and even how to design and build individual components. This level is where most of the hard edged “science” takes place, (although even at this level we need to use some judgment, e.g. weight vs stiffness vs material cost vs manufacturability….). There are probably plenty of people around a uni who can offer you advice about component level design. It is also the level of design where you can spend lots of time and effort refining, for rather small gains overall.

    Level 2 vehicle integration is where things start getting interesting, and this is where the good teams begin to shine. This is how, for instance, how your diff choice or your inner wheel packaging interacts with your suspension geometry, how all the suspension system ties in with the chassis, how power delivery matches up with tyre grip characteristics / chassis geometry, etc. In my year, we learnt some interesting lessons about integration when our choice of 10” wheels, large camber gains and floor mounted shock absorbers (all justified at an overall vehicle level), resulted in next to zero shock movement. We had to make some rather ugly tetrahedral upper a-arms to get around it, but we learnt from it.

    Visually, you can get an idea of integration by how well load paths are fed into the chassis, or how the various controls sit comfortably with the driver. Teams could possibly assess their success at this level in terms of the overall handling of the vehicle, drivability, and overall track speed. Certainly when you see a Cornell or a UWA on track and at their best, you can see the effects of a well integrated vehicle.

    Getting your Level 2 vehicle integration right is a pretty complex task, and is certainly not achievable simply by optimizing all your Level 1 components and then bolting them all together. Personally I found this Level 2 stuff to be the most technically challenging of the tasks that I faced, as it requires wisdom that you just don’t have as an incoming FSAE designer. Experience is the key and assistance and advice from alumni and design judges can be a wealth of information in this respect. (I am loath to say, that your academic support at uni might not be much help at this level. Once again, most academics are hard edged scientists / researchers, and their expertise is usually more about depth than it is about breadth. They are not often too helpful when trying to reason your way through a complex maze of competing priorities).

    Level 3 is where this particular competition gets interesting, and where I would say the greatest gains can be had for the least impact on your time and money. I’d also say that it receives the least attention of the majority of teams, as it seems many have already decided what their overall design “answer” is before they enter the event (usually “we’re going to build the fastest lightest most powerful car and blow everyone to the weeds”). The organizers have developed a clever set of rules that not only reward vehicle speed, but also some “non-racing” parameters such as fuel economy, cost, manufacturability and even knowledge and ability to communicate. It gives teams who may lack the resources to build a full on mini-F1 a chance to compete, but at the same time it makes the competition possibly even more complex than F1 (i.e. vehicle speed and lap times aren’t the sole measure of success). Making some effort to understand the conflicts that are inherent in the rules and the scoring formulae goes a long way to developing an integrated strategy that scores well across the whole competition. I will address this a little further later in my ramblings.

    Level 4 Project Management is just that – it is the set of tasks that ensures that the whole team works together, that deliverables are delivered in a timely manner, that key relationships are maintained with outside stakeholders, and that future teams’ chances of success are enhanced by this particular project. Level 3 competition success is an important factor, but not the only factor to be addressed at this level. Did you complete the project on time and on budget? Is your university happy with your year’s work? Are your team members / workshop staff / sponsors and supporters happy? Did you manage to put a decent effort into all parts of the project (e.g. both dynamic AND static events)? Have you enhanced the prospects of future teams by your effort? These are the sorts of questions that define success at the project management level.

    Measures of success at each level
    When you break a project up into the four steps above, you can then make sense of how to measure your progress at each level. As engineers we should be letting data make decisions for us, so it is important to understand what measures are relevant.

    Level 1: Typical engineering detail level performance parameters – masses, power figures, coefficients of friction, stiffnesses, natural frequencies, damping coefficients, piece costs, etc
    Level 2: Whole vehicle level performance parameters: acceleration capabilities in each direction (forward, lateral and braking), fuel consumption, whole vehicle cost
    Level 3: Competition points scored
    Level 4: Management level measurables – key ones I would suggest being time, money and goodwill. (I have no idea how you measure goodwill, but I’d still call it a measurable as we can get a sense of whether it is increasing or decreasing).

    From the above I’d hope it is apparent there is a bit of a “flow” occurring between levels. The individual pieces with their masses, stiffnesses, power outputs etc, all come together at a higher level to give us a complete vehicle with certain acceleration & fuel consumption characteristics. The whole-vehicle performance characteristics then tie in with our static event skills to enable us to score a certain amount of points in the competition. The number of points scored can then be tied into the dollars and hours spent to determine the overall value of the project (I’d suggest dollars / point and hours / point being the most useful tools at this level).

    It is our job as designers to try to understand this flow, and how the relationships work between different variables and different levels so that we can make wise decisions that give us greatest return for our own given resources. Many of the mistakes we make come from not taking the time to understand some of these relationships, or assuming some of these relationships are obvious or given.

    I’ll come back to this later, but note that many of the parameters that are often used as outright deciding factors by many of us in our projects, such as mass & power, are deeply buried in the detail design of level 1. If your team management is making project level decisions based on Level 1 parameters (e.g. “this year we need to lose 5kg” or “this year we need another 5hp”), then either your management is fluent in the way that these values convert across the various levels to dollars per point and hours per point, or they are misguided.

    The design path
    In a complex project like this, you need to construct yourself a logical pathway that neatly weaves its way through the above levels of integration. You certainly can’t start at level 1 component design and then work your way up. I would say a successful vehicle project plan would look something like this:

    1. Establish Level 4 Project goals and constraints, defining your measures of success for the overall project
    2. Develop Level 3 competition strategy outlining what resources will be attributed to what events
    3. Develop Level 2 vehicle performance goals based on your competition strategy, detailing whole vehicle and sub-system goals
    4. Design Level 1 components to suit sub system and vehicle goals
    5. Manufacture Level 1 components and assemble into working whole
    6. Test vehicle to see how it matches up to Level 2 vehicle performance goals, developing as required
    7. Compete at event, in accordance with Level 3 strategy previously determined
    8. Finalize project, comparing final outcomes with initial measures of success and reporting to key stakeholders accordingly.

    Notice how the process follows a bit of a “V”. We start with top level project goals, work our way down through all the various levels to define our individual component goals. We then work our way back up through to the higher levels, at each level cross referencing where we are, to where we had planned to be. The plan might be a little simplified, and we may very well do a bit of back-and-forth at the middle levels as our project might not work out as we had wanted, but the basic process is there.

    Determining a Competition Strategy
    From my observation over the years, I’d say that a large proportion of teams have very little idea of how to deal with the middle levels of the project. Many come in with roughly thrown-together ideas of Level 4 project goals (e.g. “We’re going to blow everyone away”) and then barge straight into Level 1 detail design decisions (our car needs to be 190kg, we need a Honda engine, do we want a turbo, our uprights need to be CNC’ed 7071 aluminium, what diff should we use, we really need a carbon tub, etc etc etc). The level 2 & 3 reasoning are mainly glossed over on the basis of a series of untried assumptions.

    I believe the greatest understanding of what is important in this project can be gained by some reasoned analysis at level 3. We have a very tightly defined set of rules that set out what sort of track we are competing on (70 metre long straights, slaloms of defined spacing, average speeds, etc), and we have a set of point-scoring formulae that tightly define how well we will score for given performance outcomes. Competition results can give us a good idea of what sort of longitudinal and lateral g’s these cars can achieve, and we can usually find some sort of track map with a bit of searching too, so we can’t argue we don’t know what we are in for.

    The competition rules are too complex to make absolute generalizations like “more power is better” or “less weight is better”. In some cases we have conflicts directly related to the performance of the vehicle (e.g. more power can drive down lap times but can also drive up fuel consumption), in some cases the conflicts are less direct (less weight can increase track speed but can tend to decrease vehicle robustness and reliability). FSAE is all about finding balance, and you will not find that balance point if you can only think in absolutes.

    When sorting out a strategy at this level I think it is important to stand above the specific technical details of the vehicle and look at the design on a very basic level. You are looking at the car at a conceptual level, and the goal is to establish whether a car of “x” kW and “y” kg will score better than a car of “a” kW and “b” kg. Is your strategy to try for outright straight line speed, or cornering speed, or fuel economy, or some middle ground with a bit of each? We are basically looking for trends in the rules, and specifics such as gear ratios or suspension settings are not particularly relevant at this level. (For example, when you are considering the choice between a 165kg single and a 200kg 4 cyl, it is not worth worrying about specific gearing ratios or suspension geometries of the two options because either can be optimized when you get further into the detail design). The essence of good decision making is in reducing a complex problem down to a limited number of variables that you can deal with, (and of course picking the variables that are going to give you the most useful info).

    The best few hours work I ever did in this project was to set up a simple lapsim to see how longitudinal and lateral accelerations affect laptimes, (i.e. taking the level 2 vehicle performance outputs, and seeing how they affect level 3 pointscoring). The first lapsim I did was really simple – breaking up an autocross/endurance trackmap into a series of straight lines and circular arcs, assigning appropriate lateral and longitudinal accelerations (assuming constant accel), and then finding laptimes. Change acceleration values, see change in outcome. Although very simple, it was one step up from simple “more power:weight ratio is better” reasoning, and gave some really useful results. For example, according to this simple autocross/endurance lapsim:
    - A 10% increase in lateral acceleration gives approximately 8 times the points return of a 10% increase in forward acceleration.
    - A 10% increase in lateral acceleration gives approximately 14 times the points return of a 10% increase in braking deceleration
    (I have no concern sharing these figures, because people like Pat Clarke or Claude Rouelle aren’t going to believe you unless you can prove it yourself. Or come up with your own lapsims that disprove me. Just do it).

    Although every model is an abstraction of reality in some way, (in particular this lapsim didn’t cover transients, and assumed constant forward accel whereas we are usually diminishing along the straight) I was confident that the figures were at least ballpark. Average speeds were around 55kmh, max speed was 100-110kmh, laptimes were around a second off from actual event times, WOT time was around 17%. So there were enough “ticks” there to indicate that we weren’t way off the ball.

    Note that by analysing how accelerations in each direction are affecting pointscore, we are completely removing the means by which we are achieving these accelerations. Therefore we are clearing our mind of details like whether the vehicle is a 600/4 or 450 single, or carbon tub or spaceframe, or any other design details that may be clouding the argument.

    Once you have a rough acceleration-based lapsim, you can start to extend it incrementally to incorporate lower level data. Do whatever you want, but at this point in time my own lapsim inputs include overall mass, engine power, tyre grip coefficients in each direction and tyre load sensitivity, rear axle load under acceleration, frontal area and drag coefficients, and engine thermal efficiency; and outputs are times and pointscores for each event, % time grip limited and power limited, min and max speeds, fuel used, and maybe a few other things I’ve forgotten.

    (One of the important things is to model fuel economy. Hard to do exactly, but as a start I broke it down into an overall energy load, [including kinetic energy, drag and rolling resistance], and an estimated engine thermal efficiency. Knowing petrol is around 44MJ/kg, and is around 0.7 kg per litre, you can get an idea of litres used. Presently my model predicts around 2.5 litres for the RMIT car, and around 3.2 litres for a UWA style car – which is pretty well representative).

    The importance of going through the above is that you can start to get some idea of how your level 1 detail design decisions affect level 3 competition scores. If you know how a 1kg weight difference or a 1kW power difference affects overall scores, you can start making informed decisions on your overall strategy based on engineering data, rather than “we need to lose 2kg because University X is lighter than us”.

    You can also start reasoning your way through some of the more complex issues related to this event. Rather than simple arguments like “we have to have engine X because it the most powerful”, we can start to be a little more refined:
    “We use engine Y. It has 10kW less than engine X, and this costs us approximately 30 points in straight line acceleration across the dynamic events. However engine Y weighs 10kg less than engine X, and this gains us 15 points in cornering performance. Also, the lighter weight and lower speeds save us 10 points in fuel economy, and the cost saving saves us 5 points in the cost event. Therefore we are at no potential disadvantage to engine Y, and the time saving from this simpler design gives us more time for driver training and testing”.

    (The figures might be a little different, but that last argument is heading in the direction of where we were going at RMIT a few years back).

    Reality Check
    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.

    On that note I might call it quits for now. There is plenty more to go depending on when I find the time, and whether or not anyone cares to read any of this (full marks for getting this far if you have). Any comments or feedback most appreciated.

    Cheers all,

    Geoff Pearson

    RMIT FSAE 02-04
    Monash FSAE 05
    RMIT FSAE 06-07

    Design it. Build it. Break it.

  2. #2
    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
    Malcolm Graham
    University of Auckland '06-'09

  3. #3
    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.....
    WORK ....
    Preliminary operational tests proved inconclusive.... It blew up when we flipped the switch

  4. #4
    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 - ??

  5. #5
    Originally posted by Big Bird:

    Reality Check
    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.

    Cheers all,

    I know I've been waiting years for someone to put some kind of number on points/kg.

    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'
    Cornell 02-03

  6. #6
    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


  7. #7
    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.

    Regards, Ian

  8. #8
    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!

  9. #9
    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:
    -Team members
    -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).
    Engine Head
    Columbia University FSAE

  10. #10
    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'

+ Reply to Thread
Page 1 of 19 1 2 3 11 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts