Showing posts with label engineering. Show all posts
Showing posts with label engineering. Show all posts

Friday, August 10, 2007

Do You Know...

1. The worst pickup line I've ever heard...

The worst pickup lines are those dealing with math. At the engineering date auction at school these are always chosen as the "favorite" pickup lines of engineers who embrace their nerdiness. If you Google "Math Pick Up lines" you'll see what I mean and how bad it can really get. For example, there are a lot of pick up lines involving derivatives or integrals... And then there was one that was used on me: "I know heat transfer". It's strange to think that anyone uses such lines, but they're real.

2. If I only had 24 hours to live, I would...

Wake up early enough to watch the sunrise on a mountain top. Eat a delicious breakfast of Belgian waffles with pears and strawberries, then spend time in the middle of the day with my wonderful friends. I'd spend the afternoon and dinner hour with my family, expressing how much I love them and how grateful I am to have had their love and support for my entire life. I'd like to watch the sunset at the beach, then toast the evening and celebrate my life with champagne. I'd want to retire to a beautiful house or hotel on the beach with a whirlpool tub so I could take a relaxing, romantic bath surrounded by candlelight, then make love and fall asleep in the arms of the man I love to the sound of waves crashing on the beach.

Hah...not too specific or anything. ;)

3. My sexiest feature...

My eyes. I'm not sure if anyone would disagree with me, but I have to say that I think my eyes can be pretty cool looking, especially with the right eye makeup!

Friday, August 3, 2007

To the Moon! (Part II)

The thing with instrument choice is that it can change rapidly. You have a preliminary instrument list so you can come up with an idea about the amount of data you’re going to be dealing with (which can start the design of the C&DH and telecomm systems), but when you make a decision on the mission architecture, everything can change. But you have to start somewhere, and instruments are as good a place as any.

Mission architecture is one of the most exciting and challenging areas of systems engineering. How are you going to launch from Earth? This requires the choice of a launch vehicle, entirely dependent on the volume and mass of the payload your mission will be carrying. So…you can’t even begin to decide on this until after the rest of the mission design is nearly complete. Once you escape Earth’s gravitational pull, how do you get to where you want to go? This seems to involve complex math and a lot of turns to make use of gravity assists. Just to get to the moon there are different stages – where we will be releasing the rocket boosters from the launch vehicle, where we will be firing engines to push the payload into the correct path, where we will be entering the moon’s gravitational pull, where we will enter a parking orbit around the moon, where we will send the lander down to the surface.

Beyond that, the seemingly simple choice of an orbiter, lander, rover, return capsule can turn into a heated debate. You have to have an orbiter to communicate with Earth. But should you have a rover/lander or just a lander? The cost goes up, but your samples might not be as good. And when you launch the return capsule from the moon, should it dock with the orbiter and the orbiter come back to Earth (very Apollo-like), or should the return capsule launch from the moon and shoot straight back home? Again, trades with cost, risk, and complexity (probably just a combined term for dual increased risk and cost!).

We’re using a brand new technology for our rovers in this concept. All of the senior systems engineers we’ve talked to think we’re crazy for using it, but I’m of the opinion that if people aren’t willing to take risks and say that new technology should be utilized, it won’t ever be used – and this is true for everything from space systems to new software. Plus using this solves so many potential issues that may come up because of the unknown terrain and surface conditions. And if we function under the idea that the technological development for this particular robot is being funded by the manned space program….well, we have several fewer issues with the cost AND we can say that it’s proof of technology and demonstration of capability for future manned missions.

Once you have your mission architecture, you can rethink your instrumentation if needed. Otherwise, you start work on specific subsystems. Some become more challenging than others, but in general you have to consider the following:

Communications
Command and Data Handling (C&DH)
Attitude Control Systems (ACS)
Thermal
Power
Radiation
Structures
Propulsion

Slowly, every part comes together, each fitting snuggly against the last. It’s like putting together a dynamic jigsaw puzzle. The nice thing about this type of puzzle, though, is that you can shave off a little of the edge if it doesn’t fit perfectly!

I am really excited to see what our final product looks like. And it seems as though other people are too – I was asked yesterday evening if the team would be ready for “prime time.” Apparently this guy has a new senior level advisor or something that is going to be on Lab next week. And one of the associate directors of the Lab thought it would be a great idea to have us present to this third-highest level in the NASA hierarchy.

It’s an amazing opportunity. But let’s just say that my stress levels are about as high as they possibly could be right now. As M said yesterday, I should be living in my cube with a case of redbull, my computer, and a pillow.

Monday, July 30, 2007

To the Moon! (Part I)

NASA's Constellation Program aims to return a human to the moon by 2020. As part of my summer internship, I (along with 10 other summer interns) have been asked to conceptualize one of the first missions for this program: a sample return mission to the South Pole Aiken-Basin. Being the eldest on the team (quite a new experience for me!), I was nominated to be the study lead.

What's interesting about this process is that it is truly systems engineering and requires a lot of "outside of the box" thinking. Stuff they didn't teach me in school (perhaps more so because I didn't study astronautics than because it is not taught). Knowing how to start the project was probably the most difficult thing: what questions do you ask the experts so you can develop a mission architecture that is feasible, cost effective, and innovative?

As an engineer, I'm always surprised at how these space missions always come back to the science. For a nation so steeped in technological growth and development, we do a lot more to advance pure science than most people realize. If there is no scientific objective to the mission, no goal that will advance the knowledge base of the world's scientists, then you can forget it. NASA (or any other agency I imagine) is not going to fund a mission simply to test the newest communication error correcting code or information theory advancement.

So where do you start? With the science. What do scientists want to know about where you're going? What do they already think is happening in that area, and can you prove or disprove it with your mission? From these science objectives, requirements are developed. Requirements are the bread and butter of systems engineers. The mission shall...An engineer working in the science area of a mission quickly becomes a scientist, sometimes shooting for the moon (no pun intended!) with ideas about what the mission could accomplish. And we've hit the key word: could. What the mission could achieve is a far cry from what the mission can achieve when the budget and engineering constraints are taken into account. The goal is to accomplish the most relevant and important science while staying within the other mission boundaries. It seems almost an art, knowing what the best science is, and certainly that is something that is never taught in school.

Next comes the instrument choice. Fueled by research into heritage missions and instruments that have done similar work for scientists in the past, engineers tread a fine line between incorporating new technology and increasing the risk of the mission. Yes, that instrument may have worked on MSL, but isn't it overkill for the Moon? Remembering the different environmental constraints and considering the communication delays for the instruments also presents an interesting challenge for the systems engineer. This is where technological innovation begins to come into play -- instruments are nearly always re-invented to a certain degree as they are used from one mission to the next. And it's not just true for the instrumentation: spacecraft, subsystems, rovers, landers, etc - nearly everything is retooled to take advantage of advances in research for every mission that is sent out.

I'll continue with this topic tomorrow - it's been a several week process learning it, so I imagine it'll be a several hour process writing about it!