Barometer Altitude Reading

[sabmah]

@bhunt2 @Kekahuna @hautruong36

Here is the Alt reading from the MultiWii GUI Config. https://www.youtube.com/watch?v=iZByfU7BjaY This is reading without any touching of the 10DOF after turning on the Flip MWC. I don't have ruler with me right now to record the height when I lift the 10DOF and read the chart on GUI. I will post them later with 10DOF on various height.

On config.h, #define FLYDUINO_MPU is selected for combine IMU board. I also tried with other boards like #define ALLINONE

On def.h, I added #define BMP085. BMP180 and BMP085 is software compabitle and shares same address 0x77

#if defined(FLYDUINO_MPU)
  #define MPU6050
  #define BMP085
  #define ACC_ORIENTATION(X, Y, Z) {imu.accADC[ROLL] = X; imu.accADC[PITCH] = Y; imu.accADC[YAW] = Z;}
  #define GYRO_ORIENTATION(X, Y, Z) {imu.gyroADC[ROLL] = -Y; imu.gyroADC[PITCH] = X; imu.gyroADC[YAW] = -Z;}
#endif

I added the alt hold position , Hi on AUX1 for BARO . You can see that on the Video.

These are the MSP_ALTITUDE read

root@AutonomousDrone:~/Drone/src# ./drone alt Debug is =>1 Initializing UART... Setting Baudrate to 115200... Setting Mode to 801... Setting Flow Control: xonxoff->0 rtscts->0... Device Path: /dev/ttyMFD1 Sending Command: m Data Available No Serial Data Available.

Number of bytes received: 12 Response: $M>ml

est altitude: 7 Vario: 0 root@AutonomousDrone:~/Drone/src# ./drone alt Debug is =>1 Initializing UART... Setting Baudrate to 115200... Setting Mode to 801... Setting Flow Control: xonxoff->0 rtscts->0... Device Path: /dev/ttyMFD1 Sending Command: m Data Available No Serial Data Available.

Number of bytes received: 12 Response: $M>my

est altitude: 16 Vario: 2 root@AutonomousDrone:~/Drone/src# ./drone alt Debug is =>1 Initializing UART... Setting Baudrate to 115200... Setting Mode to 801... Setting Flow Control: xonxoff->0 rtscts->0... Device Path: /dev/ttyMFD1 Sending Command: m Data Available No Serial Data Available.

Number of bytes received: 12 Response: $M>mo

est altitude: 4 Vario: 0 root@AutonomousDrone:~/Drone/src# ./drone alt Debug is =>1 Initializing UART... Setting Baudrate to 115200... Setting Mode to 801... Setting Flow Control: xonxoff->0 rtscts->0... Device Path: /dev/ttyMFD1 Sending Command: m Data Available No Serial Data Available.

Number of bytes received: 12 Response: $M>mn

est altitude: 5 Vario: 0 root@AutonomousDrone:~/Drone/src# PuTTY -sh: PuTTY: command not found root@AutonomousDrone:~/Drone/src# root@AutonomousDrone:~/Drone/src# PuTTY -sh: PuTTY: command not found root@AutonomousDrone:~/Drone/src# ./drone alt Debug is =>1 Initializing UART... Setting Baudrate to 115200... Setting Mode to 801... Setting Flow Control: xonxoff->0 rtscts->0... Device Path: /dev/ttyMFD1 Sending Command: m Data Available No Serial Data Available.

Number of bytes received: 12 Response: $M>ms

est altitude: 24 Vario: 0

[sabmah]

[bhunt2]

@sabmah

One thing I see in your flowchart at first glance is that the only place you are allowing the drone to shutdown is if it reaches the target altitude and enters the hold loop. You should be able to shut the system down really at any time, but it should be in the increase throttle loop. By the way, I do not see something in that loop stating that it would be increasing the throttle. It only says to send throttle to flight controller.

I am still looking through the other data, I will get back to you on that soon I hope.

[bhunt2]

@sabmah

We really need to see a log of the sensor data over a period of time where the sensor is held at different known heights. Preferably these heights would be a meter or so separated from each other. Think about the setup for this test and write up a quick test plan to determine the reason for such variation. I can think of several and they all result in taking data to verify.

Maybe the software can log all the sensor data so you don't need to write a separate program to do the test.

[sabmah]

@bhunt2 updated the flow chart.

Here is the Test plan. https://github.com/bhunt2/QC1.0/blob/master/Sabin-Code/TestCases/Test_case_altitude.pdf

Thanks

[bhunt2]

@sabmah I like the updates you made to the flowchart but don't you think there should be an exit directly from increasing altitude loop. Currently it would need to reach the target altitude before having an option to exit the program by some other interrupt.

[sabmah]

@bhunt2 updated the flow chart https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview#hover-control-flow-chart

I cannot get the altitude to read when testing with measuring tape. Even on stand still, the altitude is fluctuating in itself.

[bhunt2]

fluctuation can be worked with, but we need to determine what, if anything, is causing it. do you have some kind of a log that we can look at? On May 24, 2016 6:01 PM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 updated the flow chart https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview#hover-control-flow-chart

I cannot get the altitude to read when testing with measuring tape. Even on stand still, the altitude is fluctuating in itself.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/bhunt2/QC1.0/issues/30#issuecomment-221208645

[sabmah]

@bhunt2 I can post an output of my code for getting altitude which is inside forever loop. I'll post when I get home. I can't find the log options on multiwii GUI to record the alt read. All I can do is record the video of the readings like I did above.

[bhunt2]

do you want to do a hangout for a few minutes today to discuss your plans?

I don't want to force you to do anything especially if it isnt in the plan of what you guys decided on what is necessary. On May 25, 2016 1:52 AM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 I can post an output of my code for getting altitude which is inside forever loop. I can't find the log options on multiwii GUI to record the alt read. All I can do is record the video of the readings like I did above.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/bhunt2/QC1.0/issues/30#issuecomment-221334457

[sabmah]

@bhunt2 I just saw your message. I don't know if you still have time for hangout but if not , tomorrow on standup we can talk about it.

btw here is the output from my code: https://github.com/bhunt2/QC1.0/blob/master/Sabin-Code/alt_output

[bhunt2]

@sabmah Sorry, I was hoping to get back to you sooner on this. I will give you a quick summary of the options I see available for a more robust system.

1. Height initialization: It looked like every time you looked at altitude, in the GUI or in your code, the values received in each set somewhat centered around a specific value. For example, the most recent output of your code centers somewhere around -190 cm (without actually calculating) or your video centers just below sea level. We would need to run additional tests at various heights to determine if that actually is the case, then we could use an averaging algorithm to remove the noise and get a more fluid result. This could be used as our own altitude hold function or it could be used just to get to the right height and then have the altitude hold function take over.
2. Use the altitude hold function: As there is an altitude hold capability in the flight controller we could use that, but it will need to be tested. Who knows how well it will work. If it works great, use it and worry about other things. You still need to worry about getting up to the appropriate height. 2a. Throttle/Height Ratio: This option has so many ways to fail. There will be a lot of variation in the final height each time you run that part of the code.

[bhunt2]

About the flowchart, while I was going through our options for holding altitude I realized that the flow chart needs some additional changes. You should change the flow chart to a state machine having states like these: initialize, arm, increase, decrease, hold, disarm.

This is because you want your software to be checking altitude regularly to make sure that the flight controller is doing its job. You wouldn't want to complete trust in it as your current algorithm would. Therefore, it is possible that at some point you will need to increase or decrease the altitude using your software if the flight controller strays. This state machine would take care of the option that you don't use the flight controller hold function as well. The code would already be written to allow for a couple of the options we have talked about.

[sabmah]

@bhunt2 About flowchart, I agree. In my code I have states like you mentioned. I will make state diagram and up it on my wiki.

I can test out and collect data on different heights. I'm also reading on the Rolling Average algorithm to smooth out the output. Online suggestions also recommending covering baro sensor with foam to protect from other external variables affecting the baro.

[sabmah]

@bhunt2 State Diagram https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview#hover-states

[bhunt2]

@sabmah @spesialstyrker

Sabin, it is quite confusing to have both Hover States and Hover Control Flow Chart. They each show a different process of hover control. You should be using only one to depict your algorithm for hover control. You can use a flow chart for each state to show what is happening in each state or only use a flow chart and not a state diagram.

Your state diagram should just have one symbol shown for each state. The diagram doesn't show what the transition logic is except for landing. I would think that there would be some return loops on the states showing that the control stays in that state for specific logic.

The way you are depicting 'Land' in both diagrams tells me it is more of a flag than a state and should be apart of transition logic instead of being a state. If you think about landing in the case of just a vertical hover, it is just decreasing the altitude until it is recognized that the drone is on the ground.

The 'Altitude Hold' state would only be included in the case of using the built in alt hold functionality of the Flip. All that state would do is initialize that function and loop in that state waiting for a return flag or something like that. If you were to use your own control, you wouldn't have that state but instead the states would alternate between increasing and decreasing altitude states to hold at the desired height.

Either way, whichever one you decide to use you will need to make some changes as there are several cases missing from them.

One other thing about your hover function - hover [max throttle value] [hover time]
Does max throttle mean the maximum throttle value you will allow the drone to use in order to hold the altitude? Does the hold altitude function of the flight controller have a hover time as a parameter or is that just part of your control?

[sabmah]

@bhunt2 re-did the state diagram: https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview#hover-states

The hover time was part of my test before Foust's request to change it. I wanted to record how much height will the max throttle value (maximum throttle before Alt Hold kicks in) gives. I had not implemented any input keys to land like I have now.. so I had to implement some time to hover before it lands. hover time is part of my test parameter.

[bhunt2]

@sabmah @spesialstyrker

So, by what you are saying I am not certain I can rely on your diagram as you continue to make changes to your code and to the diagram and they don't seem to match. It is much better to have a clear and well laid out diagram before you start coding. If you code works the way your want and you are done with it, then make the diagram match your code.

The new state transition diagram still does not make sense. Look at the transitions.

1. Why is every arrow a bi-directional arrow.
2. Does the 'Arm' state need a loop back for !INC_THROTTLE flag? Or, should it just be a pass through state.
3. The transition logic between increase throttle and decrease throttle states is 'LAND'. How can that be the logic in both directions.
4. If decrease throttle state is the state you plan to use for landing there should be additional transition logic. I would think that in the case of landing, the drone may still need to increase throttle in the case that it is descending too quickly. Therefore, it is necessary to determine vertical acceleration.
5. etc.

Each time you get a little closer. Keep it up and I am sure you will have something perfect to present on Wednesday.

[sabmah]

@bhunt2 @spesialstyrker

Update: https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview#hover-states

I also added Follow State Diagram: https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview#follow-states

I removed the 'LAND' logic in this upadate because I realized this state diagram is for hover only. I think barometer is not reliable enough to land and we might need sonar range finder to detect if we actually hit the ground.

[bhunt2]

@sabmah @spesialstyrker

I hope this isn't too much, but I want to make sure you get as much information as possible to help you get prepared for your presentation.

You were really on the right track for getting a state diagram that included the whole system. I believe you are really over simplifying the system by thinking that you can split it up the way you have. It is hard to know exactly what you are doing in each state without some description and real transition logic. I think I get what 'Start', 'Arm', 'Inc Throttle' states do. You have 'Arm' as just a pass through state right, so no transition logic to 'Inc Throttle', I hope you will explain what the algorithm for increasing the throttle is. Like how fast you will increase the throttle is the 'Target_Alt' a flag that is updated internal to that state and is it is just a simple greater/less than compare. What does 'Alt Hold' do? Does it just initialize the altitude hold function on the Flip? According to your two diagrams, it looks like the Follow States diagram is a continuation of Hover States, is that correct? Is 'Alt Hold' then just a pass through state to initialize the hold function. If so, why does the diagram have it loop back into that state from 'Image Model'? What is the 'Changed' flag and is it updated in the 'Image Model' state? I am guessing that there should be logic from 'Image Model' to 'Calc Pitch'. Are 'Calc Pitch' and 'Apply Pitch' pass through states?

From these, it would seem that you have returned to a flow chart method and if that makes more sense to you, please go with it. The flow chart that you have now looks pretty good, but needs some explanation. For example: what is the Image Detected block? I didn't think there was any way for you to know if an image was detected until you have gotten the model. What does the follow block do that isn't already taken care of by the previous blocks?

Landing: The section in your flow chart for landing seems like it is on the right track to work with the fluctuations of the barometer. Instead of comparing current alt to start alt, you might consider looking at descending velocity as you continue to decrease the throttle. You know about what height you should be at and you know at what throttle level the motors stop spinning, so you have some data to work with to figure out when you have landed. A sonar would work as well and is part of the kit.

Let me know if you have any questions.

[bhunt2]

@sabmah @spesialstyrker

I just looked at the barometer, BMP180, that is being used on the 10DF breakout board and I have used that barometer extensively on other projects and have always had good results. This would be the first time using it on something that would vibrate so much, but you are getting the same drastic fluctuations in your code when it isn't even on the drone right? Looking at the video of MW software output the graph fluctuates and seems like it is a lot, but if you look at the Alt values in the bottom left corner you see that the fluctuation is very small.

Are you sure that your code is converting the received bytes properly? The MW software output looks more like what I am use to for that sensor.