Subscribe to rss feed

Projects vs Programs, and phase/stage structure | Project Proposals | Forum

 
You must be logged in to post user permissions login Login register Register


Register? | Lost Your Password?

Search Forums:


searchicon 






Minimum search word length is 3 characters – Maximum search word length is 84 characters
Wildcard Usage:
*  matches any number of characters    %  matches exactly one character

topic

Projects vs Programs, and phase/stage structure

print
small tagNo Tags
UserPost

10:34 pm
October 15, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1483

offline
link
print
1
0
ratedowngrey
rateupgrey

Post edited 10:35 pm – October 15, 2010 by Luke Maurits


Now that the most pressing of our new projects have names, in addition to finding people to act as leaders for them we need to decide on some structure and terminology.

On the demo project pages, we've been referring to things like what is now called Chimera as "projects", and we've had "stages" for each project, e.g. the stages for Project Chimera involve progressively larger payloads and eventually a swap from suborbital to orbital.  I think we should try to get clearly defined and agreed upon stage structures for all of the projects so that we can make the demo pages public.

First up, a point of terminology: antinode has suggested the use of the term "program" in favour of "project", and also the use of "phase" in favour of "stage".  Some reading has suggested that the usual convention with these words is that a program is made up of a series of projects.  Individual projects have clearly defined ending conditions, i.e. a project finishes, eventually, whereas programs, in principle, do not have an ending condition from the start – a program finishes when all the projects in it are finished and it is decided to add no more.  Since this is the convention, it seems to me like maybe the best thing to do would be to call the 4 new projects programs, (i.e. not "Project Chimera" but "the Chimera Program"), and have each of the stages/phases be a project.  So, "stage 1 of project Chimera" (the minimal Karman line project, previously called OHKLA) would be a project (probably called "Chimera 1") inside the Chimera program.

Do people like this naming system?  Or would they rather stick with project/stage, or project/phase, or something else entirely?  It doesn't especially matter what we call them, so long as we have a system and we use it consistently – we should have a consistent system decided upon before we actually update the website so we can make sure we stick to it.

With that said, for the rest of this post I'll use the program/numbered project terminology, just so I have something consistent to use.

In addition to deciding on some terminology, we need to actually decide on what the structure will be.  At the moment, based on the demo project pages, we have the following set up (apologies for the terrible formatting, but everybody knows by now just how dreadful this forum software is in that respect):

Cloudlab Program

  • Cloudlab 1: Minimal electronics payload featuring a

    GPS receiver and either amateur radio or GSM cellular network

    broadcasting of coordinates.  Will facilitate experimentation and

    experience with overall architecture and balloon filling, launching and

    recovery operations.

  • Cloudlab 2: More sophisticated electronics payload featuring GPS coordinate broadcast by amateur radio and GSM network (for redundancy) as well as onboard logging of data from basic sensors (temperature, pressure, etc).
  • Cloudlab 3: Twin payload system.  Primary payload

    consists of payload from phase.  Secondary payload is flight-specific

    and arbitrary.  The two payloads are connected via a cable.  The primary

    payload is able to log arbitrary digital data from the secondary

    payload, and the secondary payload is able to read GPS and sensor data

    from the primary payload.

Chimera Program

  • Chimera 1 (current): Suborbital rocket which can carry 5 kg payloads past the 100 km Karman Line (OHKLA)
  • Chimera 2: Suborbital rocket which can carry on the order of 100 kg of payload past the 100 km Karman Line.
  • Chimera 3: Suborbital rocket which can carry on the

    order of 1000 kg of payload past the 100 km Karman Line, enabling

    suborbital flight of the reentry module from Project Mannedflight.

  • Chimera 4: Orbital rocket which can deliver CubeSats

    or similarly sized payloads into LEO, enabling orbital insertion of the

    satellites from the COSMoS Program.

  • Chimera 5: Orbital rocket which can deliver on the order of 100 kg of payload into LEO.
  • Chimera 6: Orbital rocket which can deliver on the

    order of 1000 kg of payload into LEO, enabling orbital insertion of the

    reentry module from Project Mannedflight.

COSMoS Program

  • COSMoS 1: 1U CubeSat featuring solar power generation and storage, GPS navigation and radio communication with Earth.
  • COSMoS 2: 2U CubeSat combining an upgraded version

    of the above 1U satellite with a 1U orientation module and the required

    infrastructure for an arbitrary third 1U module which can pass arbitrary

    digital data to the core module for radio back to Earth.

Obviously, none of the above is set in stone – this was a first draft for the sake of demonstrating what the project landing pages would look like.  I would love to hear input from this setup from everyone, and in particular people who are going to be heavily involved in one particular program should try to have some input on its project structure.  Brmj, since you kindly volunteered to be a leader figure of somesort on the Cloudlab program, I'd like to hear your thoughts on its structure.  Rpulkrabek, Chimera seems like it will be your main focus, so if you have any thoughts on how it should work, say so here.  Antinode, I presume you would like some say with regard to COSMoS, so sing out.  In fact, COSMoS is probably the program most in need of input since what is there now I basically made up for the sake of the demo page without having done an awful lot of reading on CubeSats.

Once all of this stuff has been decided we can update the website, thereby kind of locking it in, and, if we have our ODE-predecessor decided upon, actually start work on these.  It's fairly clear, I think, how things should progress.  Each program starts with its simplest project, and no work begins on any project until all projects before it have been finished, i.e. had their stated goals completely achieved.

Should we try to get this stuff decided on in, say, one week, i.e. before next Saturday?  If people think this is unrealistic, say so, but I don't think it should be too hard.

Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

12:42 am
October 16, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1483

offline
link
print
2
0
ratedowngrey
rateupgrey

With regards to Cloudlab:

I think the following would improve on what is posted above:

  • At the moment the structure suggests that we should do one of GSM and ham radio for the first part of Cloudlab and then add whichever the other one is later for redundancy.  I think it makes sense to do GSM first and ham second, since ham represents a step up in complexity and in capability.  We should start basic, then go advanced.
  • With regard to the 3rd stage: in addition to the primary payload being able to log arbitrary data from the secondary, it should also be able to transmit it over the ham channel.
  • Also with regard to the 3rd stage: we should probably specify the exact means by which payloads will communicate.  A standard serial connection (R232) seems like the obvious choice.  This would be extremely easy to implement with Arduino boards.

Also, the wording above is perhaps unclear.  It's not technically correct than any secondary payload would be a part of Cloudlab 3 – rather Cloudlab 3 would just be the development of the one payload package which is compatible with secondary packages (which will be part of subsequent programs designed to utilise the results of Cloudlab).  We should tidy that up.

Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

1:34 pm
October 16, 2010


rpulkrabek

Member

posts 348

offline
link
print
3
0
ratedowngrey
rateupgrey

I am in favor of having programs with projects as a subset. I am not sure if we should have numbers after the program name for the project name, though. I think each project should have it's own name. I imagine that each project would have different iterations. For example, OHKLA 1 might not succeed at first, then we create OHKLA 2. These project names don't have to be voted upon, though. I am not attached to this idea. It's just my opinion.

For the roadmap of Programs/Projects, I don't think we should yet make any milestones permanent, besides the first one. Things could change down the road once we have more information involved. I think it's good to lay out what we are aiming for, though, just not have them permanent.

For Program/Project Chimera, I think this is more or less alright for now. It's mentioned that the first milestone is to carry 5km past the Karman line. What is meant by that? Are the 5kg the mass of the electronic components involved? Is it some unmentioned object? I think that all that is needed for the first milestone is to just make it past the Karman line. Somewhere in the roadmap, I would also like to start developing guidance and navigation. Perhaps things like spin control would be good as well. These things, though, might be embedded into some of the other milestones mentioned.

7:38 pm
October 16, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1483

offline
link
print
4
0
ratedowngrey
rateupgrey

rpulkrabek said:

I am in favor of having programs with projects as a subset.


Cool.

rpulkrabek said:

I am not sure if we should have numbers after the program name for the project name, though. I think each project should have it's own name. I imagine that each project would have different iterations. For example, OHKLA 1 might not succeed at first, then we create OHKLA 2. These project names don't have to be voted upon, though. I am not attached to this idea. It's just my opinion.
 


I'm not sure how I feel about giving each project a separate name with no relation to the project name.  On the one hand it would be good if we could find some way to get the OHKLA name carried across since we're all kind of used to it now.  On the other hand, if each project within each program has its own totally unrelated name, we are going to end up with a heap of names and it will be hard to keep track of it.  The advantage of a naming system like Chimera 1, Chimera 2, etc. is that you immediately know what kind of project a project is (e.g. if it starts with Chimera, it's a hybrid rocket project), and you also immediately know how advanced it is relative to other projects.

You raise a really good point though with multiple iterations within projects.  It might take, say, 5 launches of Chimera 1 (or whatever we call it) to actually break the Karman line and we need some way to number those individual events.  Perhaps we should just refer to these as things like Chimera 1 flight 3 (or mission 3, or something 3, etc?).

rpulkrabek said:

For the roadmap of Programs/Projects, I don't think we should yet make any milestones permanent, besides the first one. Things could change down the road once we have more information involved. I think it's good to lay out what we are aiming for, though, just not have them permanent.


I am happy for things to not be permanent.  It makes sense to update things as we go.  I do think, though, that each program should have a rough project map at inception so we can be sure the program is going somewhere.

rpulkrabek said:

For Program/Project Chimera, I think this is more or less alright for now. It's mentioned that the first milestone is to carry 5km past the Karman line. What is meant by that? Are the 5kg the mass of the electronic components involved? Is it some unmentioned object? I think that all that is needed for the first milestone is to just make it past the Karman line. Somewhere in the roadmap, I would also like to start developing guidance and navigation. Perhaps things like spin control would be good as well. These things, though, might be embedded into some of the other milestones mentioned.


Good point with the ambiguity.  With the payload masses in the project structure so far, I had been thinking of arbitrary additional payloads, i.e. not counting any electronics or other things which are actually part of the rocket.  Rather, there's an empty compartment at the top of the rocket and you can put 5 kg of whatever you want in there (provided it fits) and know that it's still going to go at least 100 km up.  The same goes for the 100, 1000, 10000 kg payloads later on.  These figures are a bit arbitrary, the main thing is that we progress steadily.  Perhaps for now we should just choose a figure for the first project and determine later payload limits based on some research into what kind of things we might actually want to do with the rockets.  If we want to do suborbital manned flights like Copenhagen Suborbitals we're probably going to need something like 500-1000 kg suborbital capacity.  There's probably not too much point going past that, I guess.  As for smaller stages, I guess we need to look into what kind of useful scientific equipment we may want to fly and how high we want it to be able to go.

You also raise a really good point with guidance.  It probably doesn't make sense to jump straight from unguided straight-up suborbital to orbital in a single project, since orbital is going to require pitch and spin control.  Maybe we should slowly phase that kind of stuff in during the suborbital projects.  This would also let us customise the time that suborbital payloads spend in a weightless environment.  There's probably a lot of good research to be done on this front.

Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

2:25 pm
October 17, 2010


antinode

Member

posts 64

offline
link
print
5
0
ratedowngrey
rateupgrey

Post edited 2:28 pm – October 17, 2010 by antinode


I propose the following:

  • A program consists of stages, projects, and missions.
  • A stage is a certain milestone within the program. For instance, Stage 1 within the Chimera Program would be to lift a 5kg payload to 100km. Stage 2 would be to lift 100kg to 100km.
  • A project is the development of a single end product. For instance, the "Chimera 1" rocket is one project. The larger "Chimera 2" rocket is a seperate project that can either be forked from "Chimera 1", or started from scratch.
  • A mission is a singular effort that invovles using one or more end-products from projects in an effort to further reach the next stage in the program. "Chimera 1" would be launched multiple times. Each of these efforts would be defined as a seperate mission.

11:22 pm
October 17, 2010


rpulkrabek

Member

posts 348

offline
link
print
6
0
ratedowngrey
rateupgrey

antinode said:

I propose the following:

  • A program consists of stages, projects, and missions.
  • A stage is a certain milestone within the program. For instance, Stage 1 within the Chimera Program would be to lift a 5kg payload to 100km. Stage 2 would be to lift 100kg to 100km.
  • A project is the development of a single end product. For instance, the "Chimera 1" rocket is one project. The larger "Chimera 2" rocket is a seperate project that can either be forked from "Chimera 1", or started from scratch.
  • A mission is a singular effort that invovles using one or more end-products from projects in an effort to further reach the next stage in the program. "Chimera 1" would be launched multiple times. Each of these efforts would be defined as a seperate mission.

 

This is quite clear; I agree with it.

8:17 pm
October 29, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1483

offline
link
print
7
0
ratedowngrey
rateupgrey

I agree that antinode's proposal is very clear.

My only concern, and it's a slight one, is that the stage/project distinction in that proposal may not be necessary for smaller programs.  For something like Chimera, it's entirely feasible we may need more than one project to progress between stages.  But with Cloudlab, I expect that there will be exactly one project per stage and in that case the distinction will be wasteful/confusing.  But I suppose we need to accommodate the complicated programs, so it's probably better than removing it.

If nobody else has any comments or ideas, I may make a blog post this weekend making this terminology official and setting up cstart.org/programs as a landing page.

Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

8:26 pm
October 29, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1483

offline
link
print
8
0
ratedowngrey
rateupgrey

I'm going to email brmj and ask him to post here in relation to the stage/project structure for Cloudlab, since he's supposedly going to be taking on some kind of leadership position on that program.

Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

12:57 am
November 4, 2010


rpulkrabek

Member

posts 348

offline
link
print
9
0
ratedowngrey
rateupgrey

Luke Maurits said:

I'm going to email brmj and ask him to post here in relation to the stage/project structure for Cloudlab, since he's supposedly going to be taking on some kind of leadership position on that program.


-

Is brmj taking the lead on Program Cloudlab? I tried to look for where he said so, but I could only find where he said that he would be best suited to work in the program.

In any case, TraumaPony has mentioned over at in the irc channel that #highaltitude is a good channel to discuss high altitude balloons. This channel seems quite active, so, anyone involved with Cloudlab should definitely check it out.

On another note, TraumaPony tried to get a forum account. He went through the process but never got the email that contains the password. I tried to make a test account, but the same thing happened to me. How can we fix this? Is this something Rizwan can handle?

5:57 am
November 5, 2010


rpulkrabek

Member

posts 348

offline
link
print
10
0
ratedowngrey
rateupgrey

rpulkrabek said:

On another note, TraumaPony tried to get a forum account. He went through the process but never got the email that contains the password. I tried to make a test account, but the same thing happened to me. How can we fix this? Is this something Rizwan can handle?


-

This is now figured out. On both occasions, the email that contained the password was considered automatically as spam.

11:32 am
November 5, 2010


antinode

Member

posts 64

offline
link
print
11
0
ratedowngrey
rateupgrey

rpulkrabek said:

This is now figured out. On both occasions, the email that contained the password was considered automatically as spam.


 

This happened to me as well. I received a PM notification email and gmail flagged it as spam.

small tagNo Tags

About the CSTART – Collaborative Space Travel and Research Team Forum

Forum Timezone: UTC -6

Most Users Ever Online: 59

Currently Online:
2 Guests

Currently Browsing this Topic:
1 Guest

Forum Stats:

Groups: 4
Forums: 36
Topics: 513
Posts: 3808

Membership:

There are 362 Members

There are 2 Admins

Top Posters:

Rocket-To-The-Moon – 685
brmj – 402
rpulkrabek – 348
DenisG – 69
antinode – 64
J. Simmons – 46

Recent New Members: kelley, Robinn, kasperholly, sharonn, alexander007, shekhar

Administrators: Luke Maurits (1483 Posts), Rizwan (170 Posts)



 
share save 120 16