Mini Falcon 9 Uses NASA Software

[T-Zero Systems] has been working on his model Falcon 9 rocket for a while now. It’s an impressive model, complete with thrust vectoring, a microcontroller which follows a predetermined flight plan, a working launch pad, and even legs to attempt vertical landings. During his first tests of his model, though, there were some issues with the control system software that he wrote so he’s back with a new system that borrows software from the Space Shuttle.

The first problem to solve is gimbal lock, a problem that arises when two axes of rotation line up during flight, causing erratic motion. This is especially difficult because this model has no ability to control roll. Solving this using quaternion instead of Euler angles involves a lot of math, provided by libraries developed for use on the Space Shuttle, but with the extra efficiency improvements the new software runs at a much faster rate than it did previously. Unfortunately, the new software had a bug which prevented the parachute from opening, which wasn’t discovered until after launch.

There’s a lot going on in this build behind-the-scenes, too, like the test rocket motor used for testing the control system, which is actually two counter-rotating propellers that can be used to model the thrust of a motor without actually lighting anything on fire. There’s also a separate video describing a test method which validates new hardware with data from prior launches. And, if you want to take your model rocketry further in a different direction, it’s always possible to make your own fuel as well.

17 thoughts on “Mini Falcon 9 Uses NASA Software

  1. Disclaimer: I have not watched the video
    It’s important to bring up that it’s illegal (in the US) to build/use/own guided rocket-driven devices. It’s not illegal to implement stabilization, altitude control, landing (like I’m assuming they’re doing here), or other features that don’t directly lend themselves to building an actively targeted missile.

      1. As long as they’re flown in accordance with FAR 101 or FAR 107 rules, it would seem they’re perhaps somewhat legal.

        This would, of course, restrict you from including an explosive payload, and would basically require that they be operated within visual line of sight of the party responsible for their control, away from controlled airspace, and without flying over people.

        Awkward, I know, but a true supervillain should be able to adapt and overcome even in the face of such stringent requirements :)

    1. The Second Amendment of the United States Constitution reads: “A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed.” ….. surely this includes guided cruise missiles? Maybe have a licensing system if you want to carry one concealed upon your person in a public place?

  2. Are you kidding me? NASA has produced _THE_ best software in history. They average one bug per 420K LoC. That’s unheard of anywhere else, including the medical device industry where it’s literally life or death.

    If there is one thing that NASA does better than anyone else in the the entire world, it’s write mission critical code.

    1. LOC? Is that lines of code or loss of control?

      Either way, 420k is only for the errors that they found. No one knows the errors that did not yet lead to obvious failure. Example, a constant could be entered incorrectly, leading to a 0.001 degree error in its course. That wouldn’t be found in most shorter trips, but a longer trip would either get off course or use too much fuel in course corrections.

  3. Neat stuff. What I’d like to see is a simple way to guide the rocket back to the landing zone in a wind or no wind, doesn’t have to land on its tail…. at least at first :) . It is so much ‘fun’ to walk a mile to find your rocket, instead of watching other HP rockets go up! Yeah, fun!

  4. I don’t really agree with the (@11:48) “things go really really well”.
    Both at the launch @11:05 and later @11:25 there is a lot of wobble in the bottom end of the rocket and this shows it’s only very marginally stable.

    Some other red flags:
    @13:48 “Large swaths of existing code in loop() can be moved … state machine”.

    This looks like the average arduino mess. A single loop is acceptable for a blinking led project, but when programs grow more complex this quickly becomes inadequate.

    I also do not agree with the control loop discussion @06:13. It’s simply not true that speeding up the control loop is always better. There is really not much to be gained once the control loop is about 20 times faster then the mayor time constants in the system. I have not looked at the code, but it seems like control loop is calculated at some variable rate. This makes a control loop very much more complex, because pretty much all “constants” in a control loop are dependent on the sample time. Normally all this complexity is avoided by just running the control loop at a fixed rate, for example by slaving it to an ISR or even using an RTOS (maybe overkill, but an RTOS does make the high-level software design easier to understand (but also adds lots of hairy details).

  5. The SW failure is why it’s a good idea to have an independent and simple backup for ejection charges. On my L3 launch I used an AltAcc and a separate ejection timer (stole my kids Lego Mindstorms controller, programmed in NQC) that was set to fire a few seconds after the AltAcc charge. Used independent charges as well.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.