New Mars Forums

The modules have been designed for shuttle specific launch loads. To give an example; the fundamental frequency of the launcher imposes a stiffness requirement on the payload. The space shuttle has a low fundamental frequency compared to other launchers in the HLLV segment, just 13 Hz axial and lateral. Proton for excites at 30 Hz axial and 15 Hz. It would be doubtful that the modules could be modified to comply with those requirements new stiffness requirements.

What I have read so far is that the Japanese centrifuge module and the Russian solar power module have been canceled due to rescheduling. Our European projects Columbus (COF) and ERA where scheduled for December ‘06 and November ’07 launch. But given the fact that ST-120 will require at least 4 prior launches I don’t expect COF to go orbital prior to late 2007 or early 2008.

Reading trough the memo it seems that NASA is going breaking IP commitments. One can only guess at the long term consequences of such a policy. This is going to be interesting…..

Though I agree with most of your arguments GCNR, I don’t think it is fair to say that it is impossible to build a launch vehicle in incremental steps.

OTRAG was a very innovative concept that might have worked. With current innovation such as the flow metrics fuel pump parallel booster designs are becoming more and more feasible. Clustered boosters are to my knowledge the only way to create a launch vehicle using a step by step approach. It allows the launch vehicle developer to prove and grow their technology by doing.

I would be interested in your (likely critical ) opinion on clustered booster concepts.

Edit: Sorry, I misread your post. You didn’t actualy state that it was impossible to reach orbit in a step by step approach. The incremental development path of clustered concept would not fit your "do not pass go unless” requirements.  Yet it does allow a graduate growth to LEO and beyond. The reason why I personally like the clustered approach is because it allows the design team to gain experience on the way. I can imagine that there aren’t that many experienced rocket engineers available for hiring by alt space start ups.

Oke, maybe I should elaborate a bit further. My intention is to start a discussion about the engineering approaches or methedolgies. The systems engineering approach allows the organization of complex engineering projects. The systems engineering theory was developed during the Second World War as a result of higher reliability requirements and is still being developed today. Prior to WW2 projects where performed without a structured methodology.

During the Second World War engineering projects became increasingly complex and difficult to manage furthermore requirements became more stringent. To cope with this increased complexity the chief engineer started using a team of system engineers to develop the project. After WW2 the complexity of engineering projects increases rapidly. During this period it became clear that a systematic approach was required to cope with the increased complexity. An early method was the Program Evaluation and Review Technique (PERT) which helped during the planning. It was also found (partly trough blowing up rockets) that changes where needed in the engineering process. During this period concepts such as part traceability, change control and interface control where developed. The systems engineering process is now days defined as a iterative process of technical management, acquisition and supply, system design, product realization and technical evaluation. In theory during each step in the design process many alternatives should be evaluated and traded against each other, so that the 'best' solution will be found. A whole range of tools have been thought up to aid the engineering during these steps. One can think of functional and operational diagrams, requirements discovery trees, RAMS analysis etc etc.

In software development a similar development occurred. During the early days of software development programmers (mostly scientists) wrote their programs ad-hoc. This wasn't necessarily a bad thing since the programs where relative simple and at-hoc writing is the quickest way to write a program that does one single thing. However, software became more and more complex and it didn't take long before a more structured approach was required. With the development of procedural languages the GOTO statement was banned and programming transformed into software engineering. Soon it became clear that even procedural languages have limitations, especially concerning code clarity and reuse. Object oriented languages revolutionized the way software is being engineered, using easy to understand abstractions. However problems similar to those experienced in system engineering arose. To assure high quality software analysis, design and implementation where separated in phases. Tools such as concepts maps, domain models, use-cases, static/dynamic object models, dataflow diagrams, etc etc where created to crystal out the design. Several abstract methodology such as OMT, OBA where (and still are) developed to structure the modeling process.

During the 90's a growing group of software developers where getting increasingly annoyed by the fact that they spend far too much time writing al kinds documents instead of code. People started to get lost in the abstract process of modeling, and lost sight of the common goal. Following this Kent Beck developed a new lightweight and very practical methodology called Extreme Programming (XP). Kent published his ideas in the book Extreme Programming Explained in 2000. XP is approach is based on increasing productivity (coding) by providing practical guidelines. Two vital features of XP are pair programming and writing tests prior to the actual code. The result has been phenomenal. Software is developed more quickly, code is of higher quality and programming has become much more fun. XP also stimulates communication with the customer which prevents requirements mismatches.

One of the first steps when converting to XP is to rearrange the office layout so everybody can directly communicate with each other (no more cubicles). A strong aspect of XP is that it doesn't rely on theoretical iteration. The process is such that constant updating of the code is common practice. Because the structure in a XP team is less formal, communication is much quicker.

Now, the funny thing is that in the automotive and aerospace industry a similar development is happening. A new type of design practice called Concurrent Engineering (CE) is being developed by most large aerospace companies. During the CE design practice work is performed in parallel instead of series. When for example a designer has a first impression of a bonnet, a structural engineer takes this first model to start his work. He knows that the design will change and thus he will need to update his structural design. His tools are such that updates can be made in real-time. As soon as there is a update in the design or in the structure, both the designer and engineer get together, discuss the modifications and update/merge the design. The difference between ordinary, systems engineering is that all this happen naturally. All the domain experts (including manufacturing) are in the same room. Information Technology is an important requirement to enable CE. All team members need to work on the same design model. Furthermore the tools used by the domain experts must operate in near real-time.

So as one can see, there are parralels. Both seem to be developing to a less formal process with direct communication between team members and with the customer.

PO, can this technology be demonstrated in a responsible manner? What approach should we, the nut and bolt engineers take to build such a 'device'. Can this technology be ‘sandboxed’?

I second that. There is a report on the net covering two different type of cost analysis for the DC-X program. No matter what method used, the figure is between the 8-10 billion dollars spend in about 8 years. Both methods included cost reducing management methods. Also different development approaches where evaluated (direct prototype vs tech. demonstrators). It also showed that the technology demonstration path leads to faster development at the lowend of the cost figure. Yet still 8 billion (1996) dollars.

Dicktice, do you really think that you can build a space launcher with a handful of retired engineers? That's whish full thinking.

Though, I do agree that being a pessimist doesn’t help the cause. ‘Alt.’ space companies will contribute in the small launch sector and likely act as subsystem developers in larger projects. Maybe someday there will be a private launch segment consisting of operators, integrators, contractors and subcontractors. It depends on how the launch market will evolve in the next decade.

Spacenut, I'm sorry but I do not really understand youre question about the 'highest near orbital altitude'.

Maybe you can elaborate?

btw. I'm pretty convinced that a subsonic airlaunched rocketplane would be good contestend for the A-prize. It offers some destinct safty advantages compared to the booster/capsule combination. Drag losses aren't really an issue, yet the reduced gravity losses and improved engine/nozzel performance do make a difference. Ofcourse the (little) added velocity helps too. The exponential nature of the rocket equation can result in some what suprising results.

My pet concept consits airlaunched two stage rocketplane. It comprimizes a reusable Lox/LH2 'upperstage' and a refubishable Lox/RP-1 booster. Come to think of it, sound alot like 'a' Rutan tier-3 program..... Ofcourse there are other simpler ways to do it.

Anyway, if you do the math it looks quite nice. But then again, dreaming up concepts isn't that hard. The details, thats where the devil lives.

I’m not GCNR, but if may be so frank to respond. Your concept is interesting yet I see some pitfalls. One would require a large, lighter than, air ‘balloon’ to float a substantial payload mass to the edge of the atmosphere. Even at those heights the atmosphere is thick (heavy) enough to create substantial amounts of drag. To reach orbit you must obtain a velocity of approximately Mach 25! Even small sattelites in LEO experience substantial aerodynamic loads and heating at heights of > 200 km. A blimp of such size would not sustain the aerodynamic loads involved. Furthermore there is the fundamental problem of the ‘lifting’ mass inside the balloon which also needs to be accelerated.

Yet there might be an application for floating ‘space ports’. One could imagine a hotel floating sub-orbital at the edge of space. Although you won’t experience weightlessness, the view would be absolutely stunning. Getting there could be a problem though. If the size permits, the station could use a landing/docking strip. Or even use smaller balloons resistant to harsh lower atmosphere weather conditions penndeling up and down. Now there is nice SF idea.

Dreaming up new concepts is not difficult. New RLV concepts are published each year in the various Journals. All of them are technological feasible, yet none of them are being build. Why is this so? That would be an interesting question to discuss.

In the Netherlands some young kids on the farm get around on so called 'mammout skelters'. These are four wheel pedal driven 'kart' type vehicles (I have no idea how these thing would be called in the US), and go trough almost all types of terrain. Very robust equipment.

One could imagine some sort of human powered quad or trike (static stable config) inspired on these types of vehicles. A recumbent position would be preferable, in such than you can provide counter pressure against the pedals. There are many advantages compared with an electrical powered vehicle:

* Very low mass, 10 to 15 Kg range if designed by aerospace engineers using Martian design loads. Maybe even less.
* Very simple technology, thus cheap to develop and easy to repair/ fix in the 'field'. Almost all repairs on a bike can be done with just a couple of different tools.
* No direct need for onboard electronics or any other complex system that can fail. Thus a fully passive means of transportation.
* The thing is always 'ready to go'.
* Store it in parts and assemble it easily on the surface.
* No need for batteries that require thermal protection.

There are however some engineering problems. The most important will be caused by the near vacuum pressure enviourment. On of the problems in designing space mechanisms is the out gassing of volatiles. A roller bearing, for example, can not be lubricated with grease or oil, since this will outgas. A lot of work has already been performed in this field. Similar problems will also have to be dealt with eclectic powered vehicle. Yet these types of issues will need to be addressed. Furthermore the most obvious show stopper would be the pressure suit.

If the pressure suit problem can be solved, human powered transportation would be quite useful for short-range (5km radius) transportation/ exploration. Suit design must go trough some radical changes to make physical work during EVA really doable.

It would be a nice student project. At moment here at Delft two groups are working on a human powered airplane and a H.P. submarine, both for student contests.

Below are some picture of these "mammout skelters", just for inspiration.

Spray-on/ spin-on suits are the future but…

Both artificial wire mussels and electro spinning are closely related to nanotechnology and funding magnets. It is doubtfull if these technologies are really required for such a suit.

What types of systems are realy required during Mars EVA? Do we need biometric sensors? Do we need onboard computers? Do we need artificial mussels? Space.com isn't the best source, to say the least. It doesn't realy say how the various new technologies will be implemented. Yet over engineering is going to make such a project very expensive and likely cause it to be never be finished at all. Onsuit systems should preferable be limited to an air supply system which could be inspired by the modern regenerative gear used by scuba divers. And furthermore a basic radio communication system which is essential. The thermal control system for a Mars suit can most likely be implemented as a passive system.

Navigation equipment is not needed ‘onsuit’, if you are opting for ‘out of sight’ tours than you will properly take some sort of transportation aid to get you there. Furthermore GPS-like systems are simply not available on Mars. The major navigational aids will be visual terrain identification (good old paper maps based on sat imagery) and radio beacons.

The thing is, that on Mars there is no technical infrastructure to support the repair of hightech devices. IMO whenever possible high-tech solutions should be avoided, they tend to complicate thing.

Has anyone seen any experimental results of these types of suits? I can imagine that existing spray-on polymers could go a long to support the human skin against the near vacuum pressure.

btw. first post after lurking in the dark for sometime