| User | Post |
|
4:30 pm
February 10, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
This is from the IRC channel:
[15:09] * DenisG (~Denis@p5B32613E.dip.t-dialin.net) has joined #cstart
[15:09] <DenisG> hi there
[15:09] <DenisG> oh dear
[15:09] <RocketToTheMoon> Hello.
[15:09] <DenisG> no-one around?
[15:09] <RocketToTheMoon> Not too many people.
[15:10] <Elleo> hey
[15:10] <RocketToTheMoon> Hello.
[15:12] <DenisG> I actually came here to nag, but since there's no-one there's no point :/
[15:12] <DenisG> anyways
[15:12] <RocketToTheMoon> I'm here.
[15:12] <RocketToTheMoon> Can you not see this.
[15:12] <DenisG> I can, helly RocketToTheMoon and Elleo ;)
[15:13] <DenisG> who are you two?
[15:13] <RocketToTheMoon> Members of cstart.org
[15:13] <RocketToTheMoon> I doubt you would be interested.
[15:13] <DenisG> (I'm a student of Mechatronics from Germany, a semester from my Bachelor's degree)
[15:13] <DenisG> I wouldn't ask otherwise, would I?
[15:13] <RocketToTheMoon> How did you find this channel?
[15:14] <DenisG> looking at the cstart forum
[15:14] <RocketToTheMoon> I see. Welcome then.
[15:14] <Elleo> :)
[15:14] <DenisG> so, who are you?
[15:15] <Elleo> I'm Mike Sheldon, and I fiddle with robots
[15:15] <Elleo> at least officially anyway
[15:15] <Elleo> in my spare time I hack on various random open source projects
[15:16] <DenisG> what are your educational backgrounds?
[15:16] <RocketToTheMoon> Denis, have you registered on the forums yet?
[15:16] <DenisG> sorry for my indiscretion
[15:16] <DenisG> no, not yet
[15:17] <Elleo> I have a degree in software engineering and am a couple of years into a phd based around developmental robotics/AI myself
[15:18] <RocketToTheMoon> I am somewhat of a slacker. I am currently in a non-technical degree. I do have a deep passion for science and engineering and really wish that I had pursued a technical degree from the beginning.
[15:18] <DenisG> ah, okay
[15:18] <DenisG> just like to know who I talk with :)
[15:18] <RocketToTheMoon> We have another phd student on the forums (Luke).
[15:19] <DenisG> oh, can you tell me more about the other people?
[15:19] <RocketToTheMoon> brmj is currently a student at the Rochester Institute of Technology.
[15:19] <DenisG> okay
[15:19] <DenisG> how many are there?
[15:19] <RocketToTheMoon> Ryan Paulbreck works in engineering in Scandinavia.
[15:19] <Elleo> DenisG: you can probably also get a rough idea of at least the newer people by reading some of the posts in the welcome centre
[15:19] <Elleo> although some seem not to stick around
[15:20] <RocketToTheMoon> We have what we call the "core 5" members, they are the ones who contribute the most.
[15:20] <RocketToTheMoon> Ideally we would have people who live close together so that we can work on weekend projects in person.
[15:20] <RocketToTheMoon> It is time to turn our online energy into real physical work.
[15:21] <DenisG> ah, nice thought
[15:21] <DenisG> you see
[15:21] <DenisG> I would really like to join
[15:21] <RocketToTheMoon> We would love to have you.
[15:21] <RocketToTheMoon> Just join the forms and introduce yourself to the team.
[15:22] <DenisG> but I have only so much time, and I wouldn't want to invest it into a project that can't "lift off" if you know what I mean
[15:22] <RocketToTheMoon> I totally understand. Everyone is under time constraints and we can only do so much with the project.
[15:22] <DenisG> tbh, so far I have been a little disappointed
[15:23] <RocketToTheMoon> How so?
[15:23] <DenisG> the whole project organization seems a little "amateurish" to me
[15:24] <DenisG> though I don't have *that* much experience with that, what happens here looks chaotic
[15:24] <RocketToTheMoon> I think that is a fair assessment. We are not a company. At best we hope to become a fairly sizable non-profit.
[15:24] <DenisG> you see, for a software project, what is there *could* work
[15:25] <DenisG> your website is great, the forum looks fine too
[15:25] <DenisG> okay, wikis are silly and blogs/tweets are indispensable needed for PR
[15:25] <RocketToTheMoon> I totally agree. We could easily pull off the mission software using online collaboration. We need to break out into the real world though so that we can develop the actual hardware.
[15:26] <RocketToTheMoon> Why do you consider a wiki to be "silly"?
[15:26] <RocketToTheMoon> It is a very easy way to keep all of our technical ideas up to date and organized.
[15:26] <DenisG> no, you're mistaken
[15:26] <DenisG> it's not an easy way
[15:26] <DenisG> and it won't keep anything organized, nor up to date
[15:26] <RocketToTheMoon> It requires too much manual intervention?
[15:27] <DenisG> and it's way too chaotic
[15:27] <DenisG> and too confusing
[15:27] <RocketToTheMoon> I don't think that any of our current team members have very much experience with the organization of a large product. Do you have any suggestions?
[15:28] <Elleo> DenisG: make a post on the forums outlining what you think would be a better option
[15:28] <DenisG> I've been on a small engineering project with a team of three people, we only had a wiki, a mailing list, and a svn repository, and it was a disaster, even though we were experienced software people
[15:28] <RocketToTheMoon> Please. This will allow the rest of the team to see what is being said.
[15:28] <Elleo> personally I might favor documentation kept in a VCS, but I think that might be less friendly towards non-software oriented people
[15:28] <Elleo> non-software develpment*
[15:28] <Elleo> development*
[15:28] <DenisG> I'd like to first outline my thoughts here, if that's alright
[15:29] <DenisG> everyone can handle a vcs these days, can't they?
[15:29] <RocketToTheMoon> That is fine. We can copy/paste it to the forum later.
[15:29] <DenisG> anyways
[15:29] <DenisG> managing even a small project is HUGE
[15:30] <DenisG> a vcs and a forum and a wiki just don't cut it
[15:31] <RocketToTheMoon> Is there a better solution that would work in an online setting?
[15:32] <DenisG> yeah, I'm just looking for a link
[15:32] <DenisG> the problem is that the project has started off completely wrong
[15:32] <DenisG> We had some courses on project management
[15:33] <DenisG> and what happens with cstart is like a book example of a failure
[15:33] <RocketToTheMoon> I see what you are saying. It would be quite a bit of work, but I don't think that we are so far along that we couldn't start something new if it was absolutely necessary.
[15:38] <DenisG> give me a second, sorry ;)
[15:38] <RocketToTheMoon> No problem. I am interested in hearing what you have to say.
[15:46] <DenisG> sorry, my mother called *embarassed*
[15:46] <DenisG> ;)
[15:46] <RocketToTheMoon> That's fine.
[15:48] <DenisG> well, what I was trying to say: this project is far away from technical decisions
[15:48] <DenisG> but they are already being made
[15:49] <RocketToTheMoon> You are totally correct. At this point we only have a shell of what we feel is the correct direction.
[15:49] <DenisG> such decisions are not to be made lightly
[15:49] <RocketToTheMoon> We are really waiting on educated persons like yourself to come along and help turn this into reality.
[15:49] <DenisG> you need to be SURE why you chose a hybrid/liquid propellant
[15:49] <DenisG> why you need 4 fins, and not three
[15:49] <RocketToTheMoon> We are not under the impression that our little team of 5 can really do anything.
[15:50] <DenisG> why your rocket is 6m long and not 5
[15:50] <DenisG> :/
[15:50] <DenisG> do you have a specification list?
[15:50] <RocketToTheMoon> This is vey interesting. I don't have the education to make calculations like this and would be very interested in learning more.
[15:50] <DenisG> you know that about a quarter of the time is spent on *planning*?
[15:51] <DenisG> not on engineering, but on planning?
[15:51] <DenisG> on decisions
[15:51] <RocketToTheMoon> I can easily see that being the case.
[15:52] <RocketToTheMoon> We could really use someone like you on the team. It seems like you have a lot to offer.
[15:52] <DenisG> and alone specification list management is a huge issue
[15:52] <RocketToTheMoon> We need someone who knows what we are doing wrong so that we can correct it.
[15:52] <DenisG> oh dear, I'm far from knowing perfectly what to do :/
[15:53] <DenisG> I really have not that much experience, but I do have *some*
[15:54] <DenisG> you need to develop a process of engineering
[15:54] <DenisG> it doesn't help to engineer away, that's 100% wasted time
[15:54] <RocketToTheMoon> Ideally we would have several hundred active members so that everyone could build on each other's strengths.
[15:54] <DenisG> then you would need like 30 people only doing project management
[15:55] <RocketToTheMoon> I see what you are saying.
[15:55] <DenisG> that's something *all* Open Source project I've seen and worked on didn't have
[15:55] <DenisG> a process
[15:55] <DenisG> everyone just does what he deems necessary and that goes on and everything is a mess
[15:55] <RocketToTheMoon> True.
[15:56] <RocketToTheMoon> Everyone is running around doing their own little part, but there is nobody to tie everything together.
[15:56] <DenisG> no, no, not tieing everything together
[15:56] <DenisG> you have to first figure out what everyone should be doing
[15:57] <RocketToTheMoon> Got it.
[15:57] <DenisG> the problem is that it's not nearly as fun as the open source way
[15:57] <RocketToTheMoon> The real issue is numbers at this point. If we reached the point where we had 10 groups who could physically meet then each group could be assigned a specific task.
[15:58] <DenisG> I don't think that you need that many people
[15:58] <DenisG> I really don't think that
[15:58] <RocketToTheMoon> To achive the goal?
[15:58] <RocketToTheMoon> Of putting someone on the Moon?
[15:58] <DenisG> you could pull the whole thing off with 5 to 10 motivated people
[15:59] <DenisG> at least getting the rocket done
[15:59] <RocketToTheMoon> Yes, motivated and skilled. Motivation alone won't get us very far. This is the point that we are at now.
[15:59] <DenisG> skilled is one thing
[15:59] <DenisG> what I'm trying to tell you is this:
[16:00] <DenisG> everyone who joins this project has a billion ideas of what can be done in which way
[16:00] <DenisG> thinking "it will be awesome! let's do it!"
[16:00] <DenisG> "I already know how to do this or that."
[16:01] <DenisG> but that hurts more than it helps
[16:01] <DenisG> first, you have to determine what you want to do in all the details
[16:01] <DenisG> not how you want to do it, but WHAT.
[16:01] <DenisG> what are the circumstances
[16:02] <DenisG> what things must be considered?
[16:02] <DenisG> why must this be considered?
[16:02] <DenisG> thinks like the temperatures that occur between here and the moon
[16:02] <DenisG> and you can't just guess this stuff
[16:03] <DenisG> it's a lot of work to find all those things, it's really very very much research
[16:03] <DenisG> what norms/standards must be met? Lots of legal stuff to read
[16:03] <DenisG> what specifications must this or that part meet?
[16:04] <RocketToTheMoon> We have given lip service to many of these issues, but you are correct, we don't have the numbers to back up a lot of our tentative plans.
[16:05] <DenisG> a product like a car has tens of thousands of items on its specification list
[16:06] <DenisG> each item consists of a description, a minimum/maximum value, a source for that item and the reason why *these* limits have been chosen
[16:06] <RocketToTheMoon> This is very helpful information.
[16:07] <DenisG> and of course the history of changes to the item and references to other items on the specification list
[16:07] <DenisG> and it gets all very very complicated
[16:07] <DenisG> -complicated +complex
[16:07] <RocketToTheMoon> This is one place where a wiki could help straighten things out. It would make keeping track of references and revisions easy.
[16:07] <DenisG> no, it won't
[16:07] <DenisG> been there, done that
[16:08] <RocketToTheMoon> Point taken.
[16:08] <DenisG> our spec list hat only like a hundred items
[16:08] <DenisG> we just had to design a pneumatic cylinder
[16:08] <DenisG> there's specialized software for that
[16:09] <DenisG> and a hundred items you can still manage in a spreadsheet
[16:09] <DenisG> on a wiki this can't work anymore
[16:10] <DenisG> the next issue is finding all those specifications
[16:10] <DenisG> you have to do it in a structured way
[16:10] <DenisG> there are many angles from which you can start that, but most are somewhat hierachical
[16:11] <DenisG> mh
[16:12] <DenisG> there are technical norms for that
[16:12] <DenisG> I could post you the German VDI norm for that, but it won't help
[16:12] <DenisG> that's actually the standard procedure for any engineering task
[16:13] <RocketToTheMoon> So in your opinon, we have a completely unworkable management structure that requires a complet overhaul before we have any chance of success?
[16:13] <DenisG> yeah
[16:13] <RocketToTheMoon> I see.
[16:13] <DenisG> and that was just the aspect of the specification
[16:13] <DenisG> engineering decisions are just as hard
[16:14] <RocketToTheMoon> I recall reading that one of the most important outcomes of the Apollo program wasn't the landing itself, but the management structures that came from it.
[16:14] <DenisG> there is an infinite amount of combination of partial solution to each little technical detail
[16:14] <DenisG> and you have to find the one that works
[16:14] <DenisG> oh damn yeah
[16:14] <DenisG> and that's why Challenger blew up
[16:15] <DenisG> a mistake in this process
[16:15] <DenisG> someone just didn't care
[16:16] <DenisG> or didn't add the minimum temperature for the rubber rings to the specification list
[16:16] <DenisG> so that an o-ring seal just was sealing a little to bad at -4 degrees celsius
[16:16] <RocketToTheMoon> Wow, that really drives home your point. Everything needs to be done for a reason and with tolerances.
[16:18] <RocketToTheMoon> Do you mind if I post this to the forum? I think this will be very valuable information for the future of the project.
[16:18] <DenisG> oh dear
[16:18] <DenisG> sure
[16:18] <DenisG> but that's another issue
[16:18] <DenisG> what I just started to describe is called information management
[16:19] <DenisG> and what happens on the forum is really really bad information management
[16:19] <DenisG> like, posting a chat transcript
[16:19] <RocketToTheMoon> Too much information?
[16:19] <DenisG> too much irrelevant information at one place
[16:20] <DenisG> if a newcomer joins your project, he has to read all of the wiki and all of the forum to get the relevant information for him/her
[16:20] <RocketToTheMoon> Yes, it is rapidly becoming too much to handle. The trick is to get everyone to focus on one of the sub forums and ignore the others. This is where good management comes in…to hand out relevant info from other groups.
[16:20] <DenisG> you can't just post a chat log here, some simulation results there, where the simulation comes from at another point
[16:21] <DenisG> no, a forum won't cut it either
[16:21] <DenisG> this simply won't work
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
10:20 pm
February 10, 2010
|
brmj
| | Rochester, New York, United States | |
| Member | posts 402 | |
|
|
Okay, granting that this is a problem, now what? How do we rebuild our orginization so that we have a better chance of success? Did Denis have any more to say?
|
Main work groups: Propulsion (booster), Spacecraft Engineering, Computer Systems, Navigation and Guidance (software)
|
|
|
10:23 pm
February 10, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
This was pretty much the entire conversation. He seemed reluctant to provide actual solutions short of finding someone who does this professionally.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
10:28 pm
February 10, 2010
|
brmj
| | Rochester, New York, United States | |
| Member | posts 402 | |
|
|
Maybe we should get in touch with that group that is now producing that open source car and see how they are managing their project.
Any chance we know what the profession or specialty this is considered is called? That would go a long way towards recruiting people with the necessary skils.
|
Main work groups: Propulsion (booster), Spacecraft Engineering, Computer Systems, Navigation and Guidance (software)
|
|
|
10:33 pm
February 10, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
There are some valid points in this, but also, I think, a lot of pessimism and exaggeration.
I reject the idea that a Wiki is wholy insufficient for our tasks. There is no reason each project or each part of a project cannot have a specifications page on the Wiki which is admin-locked to prevent vandalism. Even if there are a hundred items on it, Ctrl-F will make this manageable. There are also Wiki tables you can use wich feature the ability to sort rows like a spreadsheet. I think it will do fine.
I think CSTART is portrayed in this chat being less principled than we really are. We do know why we want a hybrid rocket. We discussed and researched this extensively and made our choice for very good reasons, which are documented in the Wiki. The question of whether our rocket will be 5 or 6 meters long will naturally be determined by how much propellant it requires, and we are on the path to figuring this out in the recent OHKLA discussion threads, using the delta- v figures calculated with USOFS (and then verified on Wikipedia) and specific impulse figures taken from a published text book. As for 3 fins vs 4, this decision hasn't really been justified yet, but that's not a big deal at this stage because it is a trivial thing to change (the manner in which the fins are mounted will be entirely independent of anything to do with motor function, avionics, etc) and we are nowhere near actually building the fins yet.
It is a simple falsehood to suggest that we are progressing as a team of entirely independent agents each doing what they think is cool at the moment without any input or coodrination from others. We always post our ideas in a tentative way first and solicit feedback. People will raise objections when something doesn't fit in well with something else. Lots of ideas have been caught and stopped early this way (there was a very early proposal for a hybrid rocket design for Selene, for instance, which was very quickly decided to have lots of flaws and was abandoned). Our individual work is integrated with some degree of care and I don't think anybody would be happy going ahead and actually building something until we give our integrated plans a careful complete check over.
It is a simple falsehood to suggest that all our work remains scattered randomly around forums and chatlogs. We have put a lot of careful calculations into the CLLARE overview document, for instance, which is a centralised document which is, in fact, kept in a VCS as was discussed. There is no reason we cannot also have a big "CLLARE book of numbers" managed and maintained in the same way if we want to.
I don't mean to be too negative. Project managemet is definitely a weakness of ours, and we do need to improve on it and find software and people to help us do this. This will be especially true for CLLARE, where the stakes will be higher (manned vehicle) and the problems will be toughter (e.g. atmospheric reentry). For OHKLA, I think the kind of management proposed is extreme. OHKLA is a simple, unmanned rocket which is incapable of explosion (one of the reasons we chose hybrids) and will have on the order of maybe 100 parts. It doesn't need Super Management, I think our current approach is feasible for it. We just need a few more knowledgable people. Hell, if we had 30 people working on project management for OHKLA, I would resign from that project on the spot and wouldn't expect it to ever take off, that degree of management is absolutely stifling for a project of OHKLA's size and complexity, it would do more harm than good. We are not NASA and we don't want to become NASA. Do you really think that Copenhagen Suborbitals have a team of 30 people overseeing everything they do? They don't even have 30 people on their team! I would suspect that Armadillo Aerospace has less than 30 employees all up, too.
My instinct is that for advice on project management sort of stuff, we should maybe turn our eyes to the extreme/agile programming communities/philosophies. Everything else at CSTART is as light and simple as it can be while still working, management should be too.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
11:35 pm
February 10, 2010
|
rpulkrabek
| | |
| Member | posts 348 | |
|
|
I am basically in agreement with Luke. At the moment, we are fine. We are not at the stage where we are ready to begin any sort of product development. Basically, everything we have done has been concept. The work that I have put towards OHKLA I have specifically said things such as I just put a certain amount of fins there to serve as a visual or that I just made the diameter and length the way they are just to serve as a place holder. I think it's rather obvious we need some calculations as to choose the size, which has all been discussed before. I think everything we have done thus far has been pre-draft type work.
I also agree, however, with Dennis. Project management will go a long way for us and we should incorporate something once we start drafting up these concepts. I have asked when we formed CSTART how we would handle PDM (product data management). With each product we design, there is certain data associated with it, such as: ID #, a description, person in charge, created by, checked by, approved by, creation date, product group, material, general tolerances, surface treatment, painting, color and more. We then also need a system to determine what state the product is in (Draft, Ready, Checked, Prototype, Pilot, Released, Retired) as well as the people who approve of these promotions. Some of this information will go to the CAD document for the manufacturer and some of it will go to some system like SAP or Oracle. A PDM system also describes a products structure, such as what parts were used to create the assembly and can then also say that this one part was also used in these other assemblies.
At the moment, I don't see a desperate need for this. When we grow, we will see a need for this. I often wonder if we can use our mercurial repository for this. If somehow some application developer will come along and create a front end that can check a product out, have drop down menus for the attributes needed to assign to the product and then check it back into the repository. Maybe it could something as simple as a text document, but is then capable of making the data searchable.
Let's also not take Dennis's comments lightly. I see him as a new comer giving us his idea of a first impression. There are areas in where we can improve greatly to provide a good first impression and then attract new users. We should also find a way to let the new comers know that if there is something they don't like they should fix it or suggest ways for us to fix it.
|
|
|
1:35 am
February 11, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
I can't say for certain, but I am willing to bet that there is a decent range of project management web applications which can take care of this sort of thing, storing the data in a MySQL or PostgreSQL database. There is probably an open source solution like this out there. Maybe we should look into it and see if Rizwan can get it set up on our server?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
1:38 am
February 11, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
rpulkrabek said:
Let's also not take Dennis's comments lightly. I see him as a new comer giving us his idea of a first impression. There are areas in where we can improve greatly to provide a good first impression and then attract new users.
I agree with this wholeheartedly. I somewhat regret wording my above post so strongly. I do think Dennis' comments are important, and we should act on them. I just don't want us to get bogged down or get out of control with management stuff. We should try to keep it light, but obviously it has to work.
In the early days, we talked a lot about having small monthly meetings/reports with representatives from the various CLLARE workgroups coming together and having everybody touch base with everyone else so we can see when one group's work impacts on anothers and make sure everything is compatible and well integrated. I think that something like this (with the frequency maybe increasing to fortnightly or even weekly as we pick up more people and activity) could work well.
We might also consider that once our overall plans are nearing completion, raising a few hundred dollars and getting a professional consultation to give them a brief look over and offer comments. People from somewhere like Armadillo Aerospace may be willing to do this for us fairly cheaply.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
2:05 am
February 11, 2010
|
DenisG
| | Saarbrücken, Germany (GMT+1) | |
| Member | posts 69 | |
|
|
Hello.
I'm sorry if I came across in a know-it-all manner, but I strongly feel that way. A big project like CSTART and even a "small" one like OHKLA definitely does need product management. And I definitely don't think that a wiki will do it. Wikipedia tables are a hassle and extremely inflexible. There's requirement management software out there (e.g. http://sourceforge.net/projects/osrmt/ ). I don't believe that one should start any engineering without having an overview of what the requirements are. I don't see how even OHKLA will work without full knowledge of all the requirements for that project.
Also, having all decisions somewhere on the forum or in the wiki is too chaotic. I'm not convinced that you have thought through all possible ways of implementing propulsion engines. Is it that hard to document your decision process in a concise way?
My suggestion: please look into product management, especially into requirements management and decision methodology. I found http://www.jiludwig.com/ to give a good first overview. Also, maybe this paper might give some overview on decision finding: http://fie-conference.org/fie9…..s/1172.pdf (did only skim over it, had no time to read it thoroughly yet but it seems okay).
I'd like to see a process like this: You have a requirements list to base decisions on, so whenever a technical problem comes up, you can meet on the forum or in irc or somewhere else and have a discussion/brainstorming/whatever to find a solution. Maybe you also do simulations and calculations. Then you put together everything that was mentioned and thought of (maybe also in tabular form, a decision table) on a wiki page. There should be all ressources that were used in the decision process, the weighting method used to decide which way to go, all simulation parameters, data, everything you need for a review of that decision concerning this problem.
Add that decision to a technical database. In the process of engineering, add all the parameters, CAD drawings and calculations that were created in solving the problem.
This way no older idea is lost and decisions are transparent and can be communicated efficiently.
|
|
|
2:13 am
February 11, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Thanks a lot for the osrmt link, that will definitely be something to check out.
The biggest problem I can see with the process you outline – where no actual engineering work begins until a complete requirements list has been drawn up – is that it means that nothing can happen until we have people onboard with the knowledge to sketch out all the requirements in detail. We simply don't have all the right kind of people yet, and it will be very hard to attract those people if we have nothing to show them so far, merely saying "Come, join us, in a few weeks or months when we have enough people we'll have a big requirements party".
In some projects, where lots of parts of the overall system interact with lots of other ones, this approach would definitely be required. But where there is considerable modularity, I think it is okay to break things up. For instance, right now we have very little specified about the avionics for OHKLA. But this is completely irrelevant for, say, choosing the propellants to use or designing an optimally shaped expansion nozzle. It is entirely sufficient to have an upper bound mass estimate for the avionics module and work on propulsion from there.
With regards to propulsion, we carefully considered the trade offs of solid, liquid and hybrid engines and chose hybrids. The fact that hybrids are an ideal choice for small, amateur products has received extremely wide recognition. If you want to try to convince us otherwise, though, or point out options you think we may have overlooked, then we absolutely welcome this. Just make a post in the relevant part of the forums and we will be all ears.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
7:41 am
February 11, 2010
|
DenisG
| | Saarbrücken, Germany (GMT+1) | |
| Member | posts 69 | |
|
|
Actually, a specification list is a working document. It grows and changes during the engineering process. That's not the point. The thing is that, as far as I can see, theres no such thing at all!
Regarding your decision of using hybrids, don't get me wrong: this was just an example, but a promiment one. Where can I find the documentation of your thinking process that led to the decision? What information was considered? Where do I find it? What was the reason for that?
Documenting and having defined decision processes is quite important. Not only is a decision more objective and more thought out, but also you already have documentation. If you want to reuse some part later on, you might want to see why you decided it to implement something this way and not that way and also you can immediately see: what was the alternative? why have you choosen this length this way and geometry conical instead of cylindrical etc etc. Also, a newbie immediately sees what decisions have been made and why and has a much shorter adaption time. And then, of course, is the educational aspect. People can learn an infinite amount when going through a well documented decision process!
Maybe a industrial strength database system like SAP is not needed here (even though it would help a lot), but for documenting decisions a wiki should suffice. The problem with that is not a technical though, but one of discipline. Following a process and documenting is boring and irritating in the beginning, but, IMO, it has to be done.
|
|
|
7:52 am
February 11, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Okay, my bad, I did not realise you were refering to a dynamic requirements/specs document. That sounds quite fine.
I do think that a database of design decision justifications is a good idea. Maybe we should look into an open source web app that could help this this.
As for the hybrid thing, the decision was mostly made in the forums here, and you can read a brief summary in the Wiki here.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
8:01 am
February 11, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Actually, I am not sure why I suggested looking into web apps for keeping a design decision database. A Wiki page will work just fine for that. I will set one up now for our current two projects and work on filling them in soon. This will also be a good way to highlight which of our current ideas are well justified and which are fairly arbitrary.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
8:21 am
February 11, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
There are now design decision list stubs for CLLARE and OHKLA in the Wiki. Obviously there is some work to be done to fill these out, but they are at least a start. If you have any specific comments on how best to structure/format the lists I would be very happy to hear them.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
6:04 pm
February 11, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
Post edited 6:06 pm – February 11, 2010 by Rocket-To-The-Moon
Luke,
Speaking of wiki pages. One thing that has been bothering me lately is that we don't have a big list of what pages exist on the wiki. For me it is very difficult to track down specific pages in a timely manner. As of now, one has to play "chase the wikis" to find some of the deep burried pages. One thing that I may do this weekend (a nice 3 day weekend for those of us in the US) is to make a new page that links to every single page on the wiki. I will try to give it some sort of logical flow so that stuff can be found rapidly.
Does this make sense or is there a better way?
Edit: We also need some easy links to things like online whiteboards, Google docs….a CSTART toolkit if you will. I saw in the chat log that you were using one yesterday. Is it possible to make a CSTART whiteboard that we can use (permant link) or do we have to create a new session each time?
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
6:07 pm
February 11, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
There is this automatically generated listing. Is that what you had in mind?
Admittedly it would be nice if that listing was a bit more structured – different levels of indentation corresponding to different projects, workgroups of projects, tasks of workgroups, etc.
It may be possible to achieve this by consistently using MediaWiki's category capabilities and finding an automatically generating listing that takes these into account, but I am not sure.
Something like this would be a good idea, though. It would be a huge help in getting the Wiki tidied up and made more up-to-date for SpaceUp, which might be another good thing that people with a long weekend could focus on.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
6:10 pm
February 11, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
Yes, that is pretty much what I had in mind minus catagories.
Anyway, back on topic I guess.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
Login 
Register 
Search 
Home
Topic RSS 
