Log 10

I’m feeling amazing today! Maybe is because I’ve just cracked FUEN1!

Yes, you read right, I’ve just cracked this fucking problem for good! You are probably asking yourselves “how?”, don’t you? I’m gonna tell you how, but first, let’s do a quick previously.

Previously, on “The Aurora Program”: I’ve got this problem that I’ve named FUEN1 (Fucked Up Error Number 1) that appeared during my tests with the guidance computer. I’ve made one algorithm to integrate the kinematics of the orientation quaternion (you remember this guy, don’t you?) in real time (which means my algorithm is processing data as soon as they are acquired from the gyro sensor) so that I can have the current orientation quaternion and, therefore, I can know where the sensor is pointing at. Anyway, I’ve proposed a test to validate my algorithm, which consists in rotate the sensor by 180º around one of the main axis and the expected outcome was the real part of the orientation quaternion going from 1 to 0, while one (and only one) of the imaginary terms doing the opposite. That wasn’t happening.

Now that I reminded you of FUEN1, let me tell you guys how I solved it (“in your face FUEN1!”). Yesterday, when I went to bed, I’ve had this spark in my head: what if the problem is the speed of the calculations? In other words, what if my algorithm is calculating things so slowly that my integration process is accumulating a huge amount of error? (the longer it takes to perform the calculations, the bigger is the time step needed to perform the integration process, and the bigger this step is, more “wrong” is the answer calculated over time!) With this question in my mind, I had only one option: to implement the algorithm using C++ (the programming language), instead of python, and upload it directly in the micro-controller, instead of testing it, first, in a Raspberry Pi. So the main idea is to bypass this test step with the Raspberry Pi and go directly to the micro-controller that is going to be the guidance computer. You already know the outcome of this, it worked just fine! (That’s what I’m talking about!)

So now I’ve made a huge progress in the guidance computer. Not only did I cracked this fucking problem, but also I’ve already implemented the algorithm in the hardware that is going to be the guidance computer. Am I awesome or what?

Log 9

While I’m stuck in FUEN1, let’s talk more about the current status of the project.

Nilson is finishing to adjust the Von Brawn’s measurement station and is going to be fully operational by the end of the week, so we can test saturday morning. We have 2 rocket engines on stock, ready to be fired. One of them I think won’t work well because we didn’t cook right the fuel, so we are going to start the tests with this one. The other one will hopefully work fine, but I think we are going to have bubble issues. I didn’t told you guys that in all of our former tests, the combustion wasn’t uniform. I have this theory that air bubbles were formed in the middle of the rocket fuel and they were messing up with the combustion process. So after saturday’s tests, if we have no surprises (like things blowing up!), we are going to cook the next amount of rocket fuel in an electric pan, so we can avoid sugar caramelization and in the same time dry the fuel as best as we can (humidity is a serious problem!). I know just the solution of our bubble problem (if my theory is correct, of course!). We can put smaller amounts of rocket fuel inside the PVC tubes before compress them with a piece of wood (we already compress the fuel, but I think we are putting to much fuel before each compression). After that, when we make the hole (we have to make a hole in the center of the tube to act as a combustion chamber) I’m gonna compress even more the rocket fuel. So I think our next rocket engine will be just perfect.

Ok, as I told you, I’m still stuck in FUEN1 and I don’t know when I’m gonna find the solution, so the guidance computer (formerly called embedded computer till I realize this name sucks!) won’t be ready soon, but fortunately we have plenty of work to do, which means daily logs for you guys (uhul)!

Log 8

We’ve reached the mark of 8 logs (yay) and we know that 2^3 = 8. You know what that means? Absolutely nothing!

Today I was trying to fix the problem with the IMU related to that 2^14 division that somehow was working and I didn’t know why. I’m going to call this problem FUEN1 (Fucked Up Error Number 1). So as I told before, FUEN1 was a problem I was having when I divided the integer number from the gyro sensor by 2^15. I thought I’ve fixed up this problem dividing the integer by 2^14 instead of 2^15, because the test results seemed to be correct. So today I decided to crack for real this problem, cause the division by 2^14 don’t make any sense. I looked at my code to see if I could find any minor mistake and guess what? I found it! Ok, that’s not entirely true, I’ve found one mistake in the integration process that seems to be mostly (yeah, mostly, not entirely!) the cause of FUEN1. After I fixed the problem and returned the division back to 2^15, the real part of the quaternion was reduced from 1 to 0.2 after a 180º rotation around the x axis. FUCK! It’s still wrong! Ok, calm down, is only a minor problem and I have the feeling I’m gonna solve it soon. While I can’t figure out the other source of FUEN1, I’m gonna talk a little bit more about some aspects and milestones of the “Aurora Program”.

As you already know, me and my friend Nilson are trying to make a rocket model using rocket candy. You also know I am an engineer (and so as Nilson), more specifically, a control engineer (perhaps one day I’m gonna use my awesome teaching skills to teach what a control engineer does). We already tried a few rocket engines to test the burn, but all of them failed in some aspects. The first one failed because the ignition system was manual (we had to light the rocket using a match), so it melted the engine because it slowly burned from the outside. The other two almost killed us (I’m joking, but it was really dangerous!) in the sense that we weren’t expecting the engine to be so powerful. In the last on, we’ve used an electrical ignition system and ignited the engines from the inside. The result was a terrible death machine that burned from inside out in less than 10 seconds and generated enough thrust to free itself from the constraints we’ve made and began to chase us till the fuel ended. Can you imagine two guys running from an uncontrolled rocket engine burning like hell?! Ok, I’m exaggerating a little bit, only Nilson ran, I was to frightened to move! But now we have the Von Brawn measurement station with us, so I have the feeling that next time we are going to have our first success. Hopefully this week we are going to test another engine, but until there, you are going to read a lot more of the bullshit I write =)!

Log 7

Look who is back! Meeeee!

Ok, that was stupid, lets get to business! This weekend I did nothing about the project (sorry guys), but I’m happy because I just saw the lunar eclipse that happened today. And I’m very pleased to announce that Von Brawn’s measurement station is ready and operational (yay!), so in a few days we are going to test the equipment with some rocket engines!

So that’s it for today (already?). Tomorrow I will be back with a full log about something fun. See ya!

Log 6

I think I’ve found a solution to my quaternion problem, but I’m not sure why it worked!

Ok, before you mentally ask: “Wait, what?”, let me explain. During my tests, I’ve noticed that after I rotate the IMU 180º around one of the main axes, the real part of the attitude quaternion should be reduced from 1 to 0, but it was falling only to about 0.8. So obviously something was wrong. Firstly I though that my integration process could be the source of the problem (I have to numerically integrate, in real time, some values received from the gyro sensor), so instead of using the standard Euler integration with fixed step (also called ODE1), I’m now using a trapezoidal integration with variable step. I’m also executing this integration process in a background thread (ok wait, what the fuck is a thread anyway? I’m gonna dedicate the next paragraph for this explanation), so now the integration process is way better. But the problem persisted and I had no other option but to use a POG (the art of creating a functional but fucked up code). To convert the 16 bit signed integer received from gyro sensor, in some point I had to divide this integer by 2^15 (15 because is a 16 bit signed integer, which means that one bit is dedicated to the signal and the other 15 are dedicated to the absolute value of the number). Suddenly I had this idea of dividing the integer by 2^14 instead of 2^15, and guess what?... It worked (yay!), but now I don’t know why! Perhaps it was luck, or perhaps it isn’t working at all, but I’m getting the wrong impression it is. I don’t know, I’m gonna look at it another day.

As promised, here is the thread explanation: A thread is a process that can be executed in parallel to other thread, which is different from parallel processing in the sense that multiple threads aren’t processed in the same time. Let me give an example: suppose that you have an algorithm with 100 code lines. I don’t know how or why, but you are going to split this algorithm into two threads with 50 lines each. When you execute this new splitted algorithm, you are going to realize that it took almost the same time to execute as the original one with 100 sequential code lines. This happens because they are not processed at the same time. The processor core process one line of code at a time, but switching between threads, so in one instant it processes one line from thread 1 and in the next instant it processes one line from thread 2, then go back to thread 1 and etc. Our brain works pretty much the same way, when we are “multi-tasking”.

I know today’s log was boring, so let me finish with a joke:

A Brazilian, an American and an Argentinian were lost in an island. They were found by a cannibal tribe. The tribe challenge them to go inside the forest and bring them one fruit each. Letter that day, the Brazilian met the American in heaven, so he asked the American: “What happened?”, then the American answered: “I came back with a khaki, them they ordered me to stick the fruit in my ass, if I laugh, they would kill me. So I was finishing putting the khaki in my ass when it begins to tickle, so I laughed”. The Brazilian said: “They ordered me the same thing. I was about to stick a strawberry in my ass when the Argentinian arrived with a pineapple”.

Log 5

I’m drunk!

It’s incredibly hard to write stuff when you are drunk. I have a friend that is leaving Brazil to live in UK because he is going to make his PhD in Cambridge. So we went to a bar to have some beers and celebrate his achievement. After more than 30 beers (me and the guys, of course!), I’m in no condition to talk about the project today, so I’m sorry. I know you guys will miss my extremely awesome sense of humor today, but I thing one day will make no difference. Therefore I declare today’s log a fucking useless log. Have a good night!

Log 4

Today I was programming my IMU (again, IMU means Inertial Measurement Unit) so that I can poorly estimate the attitude (attitude is a fancy name for orientation, or which direction the IMU is pointing at) using only the gyros. I said poorly because the signal is full of noise and there is something called bias, which is kind of an almost constant value that pollutes the signal, therefore is common to use different sensors together with the gyros and complicated algorithms to solve the problem. But anyway, as I was saying, I was programming my IMU in python (the programming language, not the snake!) using my Raspberry pi (before you ask what is a Raspberry pi, google it (no, I’m not calling you a moron this time, although you deserve it!)) and I figure out I must have screwed up somewhere in the algorithm, cause the resulting attitude quaternion is showing nonsensical values! I know what you are thinking right now: “What the fuck is a quaternion?” I’m going to dedicate a whole paragraph for those who mentally asked that question. If you already know what a quaternion is, you may skip the following paragraph, I don’t fucking care!

It was in 1843 that the Irish mathematician William Rowan Hamilton decided that it was too easy to operate with complex numbers possessing only one imaginary term, so he decided to add two more imaginary terms, creating the quaternion and fucking with my life! So a quaternion is a hipercomplex number with one real term and three imaginary terms. Before someone asks why the hell would someone create such an abomination (besides to screw me up), quaternions are used to mathematically rotate vectors in 3D space. They are an alternative to the well known (and equally fucked up) rotation matrices, having the advantage of not possessing singularity configurations, also called gimbal lock configurations (wikipedia is there for you!).

As I was saying, my attitude quaternion is behaving badly in the tests I’ve made. By my calculations, if I rotate the IMU 180º around one of the three basic axis (x, y or z), the real part of the quaternion must go from 1 to 0, approximately. What is happening is that, after the 180º rotation, the real part is reduced only by about 0.2. So either there is some stupid mistake fucking up my code, or my calculations are wrong. Either way, I’m too tired to find the mistake, so I will leave it for another day. See you next log.

Log 3

Today I’m gonna talk a little bit about the embedded computer. As I already told before, we are going to “science the shit out of this”, which means that we are going to gather as much info as we can from our rocket model. Yesterday I told about the measurement station and what kind of information it can provides, but what about taking some flight data? That’s where the embedded computer gets into the story.

The embedded computer will basically do three things: read info from the IMU (Inertial Measurement Unit), store the data on a SD card and deploy the parachute. The inertial measurement unit is basically composed by a gyroscope, an accelerometer and a barometer. With these three sensors we can estimate the rocket’s orientation, acceleration and height. The embedded computer is also supposed to identify when the engines burned all up, meaning that the rocket is in free fall. After a few seconds of free fall, the parachute is supposed to be deployed using a servo motor, slowing the rocket to a non killing speed.

We are going to try to implement a fourth function for the embedded computer: transmitting the flight data via RF (Radio Frequency). This one is going to be tricky, so I’m leaving the problem to my pal Nilson. For now I’m just gonna have to figure out how to fit the embedded computer, the IMU and the SD card module inside a 4cm wide tube (don’t try to do this with your cock!) and still have space for a deployable parachute and a servomotor, but I’m gonna leave this task for another day. Time to sleep.

Log 2

Today I’ve just remembered (I didn’t remembered a fucking thing, I’ve just read yesterday’s log!) that I forgot to answer the most important question of all: Why build rockets?

The answer to this question is simple, firstly because I can and secondly because I want to! No, seriously, the true answer is because I love rocket science! Since I was a kid, I used to memorize planet’s names (sorry Pluto, I will never forget you!), mission and astronauts names and I like to read about NASA’s history, how they manage to go to the Moon in the end of the 60’s and how they manage not to go to the Moon for the next 43 years (are you kidding me NASA?!). Then I realize, after playing more than 150 hours of Kerbal Space Program, that I want to use my engineering skills (yes, I’m a fucking engineer!) to build my own rocket model. It’s important to say that the goal of the Aurora Program is to learn about rocket science and have fun. Nobody needs to get hurt in the process, so safety is our main priority. “We are sure as hell not gonna hurt someone on my watch. Failure is not an option!”

Ok, after telling that, let’s get to today’s real log topic: Von Brawn’s measurement station. Probably you are thinking about asking who the fuck is Von Brawn? My answer to this question is simple, google it you fucking moron! Since our main goal is safety, we are not interested in building rocket engines and light them up pointing to the sky right away. Instead, we (when I say we, I’m talking about me and my pal Nilson) are going to “science the shit out of this!” We are building this measurement station so we can measure the thrust and impulse that the rocket engines can generate. With this information we can estimate the maximum altitude and distance the rocket can achieve. We can also test the best way to cook solid fuel (as I already told in yesterday’s log, we are not cooking hamburgers, you fat fuck!) and the best way to assemble a rocket engine.

So Von Brawn’s measurement station is basically composed of a rail with a platform and a load cell. The load cell will measure the thrust generated by the engine and with this thrust we can estimate the impulse by integrating it over time, isn’t that right Sir Isaac Newton? (I don’t even know if it was Isaac Newton who proposed this, but it seems to me that Newton’s name fits in every science achievement there is!) So in the end, the engines will be tested in the ground so we can collect every data there is about it before sending it burning to the sky, and hopefully not blowing anything up in the process.

Ok, I’ve already talked too much for today, next log I’m gonna bring something better, or not, cause the log is mine and I write whatever I want on it!

Log 1 - The Aurora Program Birthday

It’s with extremely happiness that I declare today, September 20th, 2015, the official birthday of “The Aurora Program”. This project was created by me and Nilson (yeah, you are going to read his logs too!) in an attempt to create a rocket model using rocket candy as a propellant. So let’s start answering a few questions:

1. What the fuck is rocket candy?

Rocket candy is the mixture of 66%, in mass, of potassium nitrate and 33% of sugar (yeah, fucking sugar!). So, if you cook them (mixture in water and put on the fire till all the water evaporates) you have solid fuel that looks like solid milk candy, or as we call in Brazil doce de leite.

2. Why is this project called “The Aurora Program”?

Firstly because is a fancy name. Secondly because Aurora was the name of my deceased little bunny, who died a week before I started to think about making this project, so this is my tribute to her!

3. Why writing personal logs about the project?

This idea I just had with my friend Nilson. We’ve read a book called “The Martian” by Andy Weir, and in the book there is this guy named Mark Watney (by the way, fuck you Mark Watney for being such an awesome character and fuck you Andy Weir for being such a good writer!) who is an astronaut that is left behind alone in the surface of Mars. He writes logs telling about his 549 days on Mars.

So I’ll be writing logs whenever the project status changes. Hopefully tomorrow there is going to be another log.