jbmiog / qc-embedded Goto Github PK

because else we might break the lipo battery

panic mode to safe mode from keyboard is ok

When battery is low and we enter panic mode due to that, we reach safe mode, but since the pc continues sending packets with "manual" info in the mode field we do circles forever.

We should insert a bat_high flag in safe mode and switch between modes when this flag is true.

Same for connection

I will handle that!

TA mentioned values should be between 300 and 500.

I will fix it

So guys, there are two new branches, the one is called "last_lab_working" which is the code that worked perfectly in the last lab with the difference that yaw, pitch and roll movements were too harsh.

The other one is called "new_edited_version" and basically I changed the way the motor values are computed in order for it to be more smooth. However, as I commented in another issue Wu should change again the joystick scales as I told him in that issue and we can test that as well. The only problem with that version is that we may need to calculate again the p, p1 and p2 values but this is like a 30 minutes procedure. This version is better in terms of smoothly controlling the drone and I suggest to keep that if it is proven so by the testing.

Also, we cannot divide the generated joystick value as we did, because by dividing the generated joystick values we narrow down the resolution so I think this is bad, that's why I thought of new way to calculate the motor values!!!!!!

or make this repo private...

Guys, we should still protect the chars for overflows! I'm adding this issue because else i might forget

1. Buttons
2. Senstivity

Lift: 0-127 The first half will occupy 0-32 and the second half will occupy 32-127
Roll,Yaw,Pitch: -16-15

into master

The TA just mentioned the drone, in it current state (in working branch) would fall like a brick when entering panic mode. I suggest we decrease the engine speed linearly from the current speed, when entering panic mode.

Hey,

We noticed when putting the static offset to a value like 127, and go back, we cannot go back to 0 again, but it goes to something like 5 and decreasing it will make it go to -1.

We should fix it :)

Hi, makis and I just testd and it seems that the time between each packt is 17 ms, which is different from the time in the terminal. Maybe this causes the delay?

We still haven't implemented the battery voltage check, the code is there, but it is still commented out. Time to test this!

We should implement data logging. Jeffrey declared interest

We should start thinking of that

1. No transitions when value changes
2. Blue LED frequency
3. Emergency Stop approach
4. Delay

In the temporary branch, at pc-terminal folder, at pc-terminal1.c, when creating the time loop we get the time in nanoseconds and then we divide with NANO_SECOND_MULTIPLIER which is equal to 1 000 000.

That means that we don't convert to milliseconds (10^-3) but to (10^-9 * 10^-6 = 10^ -15) which is very very small. Therefore, the packets were sent very fast. Maybe that was causing the delay issue, since the drone was receiving packets at very fast rate.

Normally nanosecond = 10^-9 second, thus in order to convert nanosecond to millisecond, you have to multiply with one million (10^6) and get 10^-3 second=millisecond. I don't know if it was the problem, but for sure the way it is written now is wrong.

in manual mode

If we implement this (it's also mentioned in the assignemnt) we can upload without power cycling the ES

Every 200 ms and send data:

battary voltage
motor values
mode
sensor data

this is mentioned in the assignment, I should not forget to do this!

we still need to check this!

MA filter for raw yaw control and Kalman filter for raw roll and pitch control is done, waiting for test.