Showing posts with label nasa. Show all posts
Showing posts with label nasa. Show all posts

Monday, April 5, 2021

Perseverance Finds Interesting Rock on Martian Surface, Zaps It

The Nasa rover on Mars, Perseverance, found a weird rock that is confounding scientists. The rover’s Twitter account published an image of a weird, pockmarked rock. It has a smooth, greenish appearance and the caption underneath confirms that scientists are stumped. Perseverance zapped the rock with its on-board laser and is trying to learn more about it.

‘While the helicopter is getting ready, I can’t help checking out nearby rocks,’ the rover tweeted in the first person. ‘This odd one has my science team trading lots of hypotheses. ‘It’s about 6 inches (15 cm) long. If you look closely, you might spot the row of laser marks where I zapped it to learn more.’

It can identify the chemical and mineral makeup of targets as small as a pencil point from a distance of more than 20 feet (7 meters). In the picture, one can see the tiny indentations on the right side of the rock where the rover’s laser hit it.

Over the course of several years, Perseverance will collect and store up to 30 rock and soil samples that will eventually be returned to Earth where labs will analyze them.

Read the tweet from the robot here...


Monday, June 1, 2020

Think Six-Sigma Code is Not Possible? You just need to think like NASA

To get high quality code in your application, consider adopting NASA’s 10 rules for writing mission-critical source code:

  1. Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
  2. All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
  3. Do not use dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
  5. The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements).
  6. Data objects must be declared at the smallest possible level of scope.
  7. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
  8. The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.
  9. The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.

According to NASA, the rules act like the seatbelt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable.

Read more here...

Monday, January 30, 2017

New Spacesuit to go with New Spacecraft

Soon, astronauts from will use a new spacecraft, the Boeing Starliner. They will also utilize the Boeing Starliner Spacesuit, a cutting-edge backup system to the new craft, bringing more safety and comfort.

Thanks to advances in materials, it's 10 pounds lighter than the exit and reentry suits worn aboard the space shuttle, with the ability to let water vapor out yet keep air in. The new helmet and visor are integrated, the gloves are touchscreen-friendly to accommodate modern controls, and the joints are more flexible, letting the brave men and women who wear it move more freely.

See this at NASA...

Friday, June 4, 2010

Atlantis final mission



End of an era - the space shuttle Atlantis is to be decommissioned after completing its latest mission STS-132. The shuttle launched on May 14, 2010, returning on May 26, 2010.

The shuttle was originally a pretty cool idea then co-opted by the military-industrial complex (i.e., the air force and intelligence community). As a 'limited reuse' vehicle, the program has been the U.S.'s sole foothold in space for quite some time. With no replacement even on the drawing board, i suspect my children won't be witnessing much more in the way of cool American ingenuity.

Heros - in short supply these days. Sigh.