The dumb part

In this chapter I will talk a lot about the acceleration, angular conversions, velocity and positioning of the copter. It is quite tedious, but I will try to make it as easy as possible.

What do we get? We get the calculated thrust from the rotors. We also hope to get angles from the angular calculations. Otherwise, this would be bad. With only this information, we can (hopefully) accurately calculate the acceleration of the copter in both the body frame as well as the initial frame. But let me first tell you about these two frames:

Body Frame vs Inertial Frame

Here you can see the different frames. The inertial frame and the body frame. The centre of the inertial frame is a point in the room, while the center of the body frame is always the center of the copter. So why do we need these two systems? Imagine if we put the center of the copter in the center of the inertial frame. Now turn the copter exactly 180° around the z-axis. If we now accelerate the copter towards the x-axis of the inertial frame, we have a positive acceleration in the inertial frame, but a negative acceleration in the body frame. Since we need both accelerations, one for the output to the Arduino and one for calculating the velocity and therefore the position of the copter to accurately calculate the distances to the walls, we have to convert the accelerations from body to inertial frame and the other way around.

So we got our thrust. This thrust is obviously in the body frame, since it is always "upwards", even if our copter is turned upside down or any other way. That is why we need this next step:

Body frame to inertial conversion of thrust and calculation of accelerations

So in this model, we calculate the accelerations with the help of the angles. These conversions are fairly well described in chapter 4 of the thesis of Hoeger (see The Main Model). There he describes the rotational matrices and where they come from. In here I won't go into much detail, you just need to know that they work! (These are in the two composite models)

So after that the thrust is divided by the weight (to get the acceleration, F = m*a), and then rotated and lastly, if we are in the z-axis of the inertial frame, the gravity is subtracted.

Now we have accelerations in the inertial frame. But we didn't consider the movement inertia yet:

Movement inertia of the copter

The movement inertia is given in kg/s. We multiply it with the current velocity and divide that by the weight in g (which is actually in kg, don't be fooled!). Then we subtract that from our acceleration and we get the actual acceleration.

Since we disregard air drag, because we don't actually want to fly very fast so drag is very negligible, we are now finished with calculating the acceleration.

Velocity and Position

Pretty self explanatory. We just calculate the current velocity and position by integrating.

Converting Acceleration to output values

So we want to output our acceleration to the Arduino. For that we need to convert it back to the Body frame, because our gyroscope is part of the copter and measuring the accelerations in the body frame.

Firstly, we subtract the gravity from the acceleration ONCE AGAIN, because the gyroscope somehow wants that? I don't really know, it's weird like that. After that we once again translate the accelerations with a rotational matrix (as seen in Hoeger). Afterwards we Scale the values to fit the output of the gyroscope which outputs values between -16384 and 16383 (for whatever reason?). Now we have the acceleration that the Arduino wants (seeing this, I might have discovered a small error. The acceleration of the arduino might also measure some part of the rotational accelerations, so I might have to look into that. For now, TODO!)

Update: I realized a small mistake in the planning of the quadcopter (or maybe the simulation): The gyroscope is actually shifted by 45° to the left. This means that, instead of the axes being on top of the four arms of the rotors, the axes are actually between the arms. To compensate this mistake, I have added a small model of a rotation around the z-axis of 45°. This is a relative easy addition to the outputs - I did not update the whole simulation to accommodate this little oversight: