Communication between Edison and Flip 1.5 Not Working

[bhunt2]

Please post information about what is happening here. Even just links to your documentation and tests is acceptable. This issue is a place for us to be able to work communicate with each other about the problem.

[sabmah]

@bhunt2 Here is the output after the parse

[sabmah]

@bhunt2 New page for Done control test plan

[bhunt2]

@sabmah

Your on the right track now. When you show the frames, it needs to be understand what represents each part of the frame and how large it is. Otherwise, if you look at the below as an example it is a little confusing. I know what it is because I have worked with the protocol myself, but for someone who is reading this and trying to conduct the test who knows nothing about it it would be very difficult.

Send Frame: $M<0105 (I don't know what this group of numbers and symbols represent and I can also see that this is incomplete because you don't include the CRC.) Hex Frame: 0x24 0x4d 0x3c 0x00 0x69 (The above frame and the hex frame do not match in several ways depending on how I interpret what you have written. If I consider each character in the send frame represented by a byte hex value they would not match.)

I hope you can see how things can get really confusing to understand even for someone who knows the system. I am not trying to pedantic, I am only trying to ensure that the system is safe and the documentation can be understand by those who will take on this project after you.

Also, to show that the first test has passed you should have a display of the MultiWii software showing the values being seen are the same. As these, I believe, are the default values you don't you can say that it shows correctly. Are these the default values you have set in the system?

By the way, there isn't really a throttle to height ratio. As the drone takes off it reacts kind of like there is a throttle to height ratio. In that it requires a certain amount of thrust just to lift off and then for a short amount of distance upward you need to increase the throttle. Once you hit a certain throttle point, the drone will continue upward until you lower the throttle again. This all would be better characterized as a throttle to acceleration ratio, but even then it will not be linear.

More to come as you update.

Thanks for getting this done. It is beginning to take shape.

[sabmah]

Thanks. @bhunt2

So, for throttle, the test would be just reacting to our up/down key stroke for throttle?

I would also like to talk about pitch test plan. We haven't come up with formula yet for pitch and throttle balance in order for drone to travel forward. The team talked about briefly but haven't come to conclusion yet. Do you want us to come up with the formula first and create a test plan for pitch? Because the pitch test plan depends on the formula itself. Right now, I can create test plan like throttle's test plan in that the left/right keystroke will increase/decrease the pitch value.

Now I'm trying to debug Arm/Disarm. It's taking me longer. Maybe I need some help on this one.

[bhunt2]

@sabmah

Test 2 should be testing whether or not your control with the keys works as you expect without hooking up the drone.

Test 3 should test the functionality of your throttle control in a real life on the drone in a controlled environment.

Test 4 should test pitch control functionality

and so on until all the functionality as been added and tested.

The formula for better pitch control must come after you have basic pitch control. You need to make sure basic functionality work before adding in more complexity. Its the difference between having open control and closed feedback control. Initially your control may be very choppy and the drone may move slowly or go too far or only move in small choppy increments, but at least you see it moving. Once you have a safe understood working environment, then you should consider how to make control more fluid by using closed feedback controls like a PID or something like that.

HELP -

Please describe what your issues are and then I will see what I can do.

[bhunt2]

@sabmah

I think that your most recent updates to the test plan are good. It is looking much more like a test plan and I can see that you are trying to think about what all the conditions might be. There are some things that you could do to make it more understood, but that would pedantic.

I am not sure if you made those updates after I gave my last comments or not, but throttle test still shows throttle to height ratio. Please review my previous comments on this if you haven't seen them yet.

Don't forget to state timing for your incremental changes during test. By timing, I don't mean the refresh rate. That is good information to note when you want to make sure your system in updating correctly. I do mean the rate at which you will increment the throttle for example. If you increment too quickly you may inadvertently send the drone shooting up into the air.

I think you are just about ready to get started on the other drone tests. I will be sleeping for the next 8 hours, so you will be on your own. I hope things go well for you.

[sabmah]

@bhunt2 I haven't made update on throttle because I wasn't sure to remove the throttle to height ratio and just add throttle control with key stroke.

Test 2 is arm/disarm test. do you want to add the key stroke test on test 2 also?

Help-

I'm sending over a yaw value (uint8_t) = 1500

hex : 0x5dc

I converted to (char) which gives me '\334' but I need '\005\334' which reflects the hex value.

[bhunt2]

where are you at with this? it has been 8 hours, so I am hoping you got somewhere with this. I can meet a little before the meeting to talk, but mornings are busy around here so I can't help to much yet.

Please describe exactly what you have done to figure this out. You should be able to just reverse the parsing process you did to get out the data from the RC request. On May 12, 2016 12:17 AM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 I haven't made update on throttle because I wasn't sure to remove the throttle to height ratio and just add throttle control with key stroke.

Test 2 is arm/disarm test. do you want to add the key stroke test on test 2 also?

I gdb the arm code. It looks like we have to reverse the data bytes when sender over the arm code. I'm having trouble getting the value to convert.

(uint8_t) = 1500

hex : 0x5dc

Convert to (char) gives me '\334'

I'm expecting '\005\334' => this is the reverse string I need to send which reflects the hex value

— 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/24#issuecomment-218491704

[sabmah]

@bhunt2 ummm.. I have work everyday. The only time I have time to work on project and school stuff is after work.

[sabmah]

I converted to hex first.

I have to write uint16_t 1500.

I converted into hex 5dc. std::ostringstream foo << std::hex << 1500;

Then, I tried to convert to string '\005\334' (this is the value we were getting back when we read RC). I'm having hard time to make it look like that pattern.

I converted to decimal which gives me 5220

[sabmah]

@bhunt2 It arms / disarms now https://youtu.be/Qsl3ngwCOoE

[bhunt2]

great job, I knew you could do it. On May 13, 2016 3:20 PM, "Sabin Maharjan" notifications@github.com wrote:

Reopened #24 https://github.com/bhunt2/QC1.0/issues/24.

— 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/24#event-659516227

[sabmah]

@bhunt2 Thanks. :) I have a draft of Test Case that looks like Kainoa's. Can you take a look and see if I'm on right path and need changes?

https://onedrive.live.com/redir?resid=875139392072F68D!324212&authkey=!APEp8BTRqrHiea4&ithint=file%2cdocx

[bhunt2]

I took a look at it and I think it is going in the right direction. Here are a couple thoughts for moving forward.

1. I think that you should have one of these for each of the tests that you outlined before.
2. You can do it all in one, but you need to outline all the steps for each test as you need to make sure that each part of the system continues to work as you make changes.

I know how I would do it, but it is difficult to explain. I would probably do the final acceptance test all in one and just separate the 'tests' with colors or borders. This way someone could go through one document and test everything from the simple serial communication all the way through to object following.

All the parts should have their own test plan so that you can record the results on it each time you perform the test. then you will be able to use that data later as you troubleshoot issues to help you resolve the issues faster.

Good luck, Ben On May 13, 2016 4:24 PM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 Thanks. :) I have a draft of Test Case that looks like Kainoa's. Can you take a look and see if I'm on right path and need changes?

https://onedrive.live.com/redir?resid=875139392072F68D!324212&authkey=!APEp8BTRqrHiea4&ithint=file%2cdocx

— 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/24#issuecomment-218970370

[sabmah]

@bhunt2 That makes sense. Thanks. Faust put Hau in charge of Final Acceptance Test plan. So, I would have my own test plan and Hau's Final Acceptance Test Plan?

[bhunt2]

ok, but you could still have a final acceptance test plan for the flight control part. this makes it so that if soneone comes after you and needs to change something or add something, they should be able to use your tests with possible small variatons to test that their changes worked.

load up your work into github and i can take a look.

ben On May 14, 2016 12:24 AM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 That makes sense. Thanks. Faust put Hau in charge of Final Acceptance Test plan. So, I would have my own test plan and Hau's Final Acceptance Test Plan?

— 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/24#issuecomment-219075683

[sabmah]

@bhunt2 @spesialstyrker @hautruong36 @Kekahuna Throttle Test: https://youtu.be/lP3PoHmbrXI

[bhunt2]

It looks good. I hope you have completed your test plan though. I haven't seen any comments telling me that there were updates, but there were definitely items that that needed to be added or changed. I also had asked that certain things be done before you ever use it on the drone. I don't want be a Debby Downer, but I was pretty clear about those things on several occasions. It has to do with safety of operator and wanting to protect the drone itself as well since it is all quite expensive. Please send me updates to the test plan so that they can be approved. Then continue your work. You are doing great, I just need to make sure that certain things aren't missed. thanks, Ben On May 16, 2016 4:30 AM, "Sabin Maharjan" notifications@github.com wrote:

Reopened #24 https://github.com/bhunt2/QC1.0/issues/24.

— 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/24#event-661044893

[sabmah]

@bhunt2

https://onedrive.live.com/redir?resid=875139392072F68D!324236&authkey=!ALIE8A0Vv1F15j8&ithint=folder%2c

Sorry it took a while. Faust really wanted to see the drone fly so I had to jot down on coding.

I separated the test cases like you said from your comments earlier. I did not know what to do with expected result on throttle and throttle/pitch test. I could say it flies certain height and distance but I don't know how high it will fly given the frame.

[bhunt2]

@sabmah @spesialstyrker

Here is some feedback for what I see from the tests:

Arm and Disarm Test:

• The frame is still hard to read. If I were someone who has no experience with this system, I would not know what to do with this frame value. You have it mixed with chars and integers. It is not that important to know what each part of the frame means, just that it is understood how to perform the test.
• CRC
• There should either by another column giving instructions or add the instructions in the Action column that tells the Tester what to do to arm or disarm the drone. From this, I don't know what files to access or what commands to run to perform this test. In order to make it reproducible so that it is the same every time you run, you need to have everything spelled out and follow it each time exactly. This will help you troubleshoot when you run into problems.
• No information about tests that you performed as it would seem you have passed this point and therefore should have some data here.

MSP_Read

• Same as above. (CRC, frames, test data, etc.)
• For expected result, you should know exactly what to expect when sending the command. You know what the values have been set to and you haven't changed them, so in this case, you can expect exact values back.

Throttle_Control

• Same as above (frame, CRC, instructions, etc)
• Does it make sense to have the throttle setting start at 1500? This is configurable and if you are using the new Flip 1.5 you should probably either have Hau configure it accordingly or follow his instructions for doing so to ensure you are working with the same configuration that will be used during flight. The throttle should start at a level where it is too low to move the motors or at least so that it doesn't produce enough thrust to take off.
• No expected results shown: In the first few steps you should just be testing that the throttle values change accordingly when you use your arrow keys. Then in later steps you can say that you connect the drone and test that the drone motors begin from a stopped position and then by increasing the throttle the begin to spin and produce thrust. Finally, in the last few steps (with a requirement that the others have passed) you can increase the throttle until it takes off. In this case you must include the instructions that it is tethered down and there is nothing and nobody within then possible range of the drone movement.

Throttle_Pitch

• Same as above
• If you follow the same kind of pattern as explained in the throttle test I believe you can figure out an appropriate testing procedure for this as well.
• Please make the changes as needed and let me see it again.

Please load the tests into GitHub instead of in your OneDrive. We use GitHub so that there is easy access to version control of the files. Please it makes it so that everyone can learn from your example of a good test plan.

Good job and keep it up.

[bhunt2]

@sabmah

The other option is to have the instructions in the Setup section as long as you don't need different instructions for different steps. If you have different instructions for different steps, they should be placed appropriately with the steps themselves.

[bhunt2]

@sabmah

Now, if you feel that the your documentation is good enough, you can reference your documentation in the setup section for the Tester to go to and view instructions that would make sense for accomplishing the steps. This does not mean have the instructions for the specific steps in your documentation, but having a reference for sending specific commands or how your control firmware works so that they can accomplish the test. As these kinds of things should be in your documentation anyway (i.e. go to this folder and type into the command line to arm the drone.) this may be your best option as it will also make sure that your documentation is in order.

[sabmah]

@bhunt2 Thank you this is helpful. I will keep it posted.

[sabmah]

@bhunt2 For read only values like attitude where values depends on what position is the Flight Controller , can I have column that says Expected Total Bytes?

https://github.com/bhunt2/QC1.0/blob/master/Sabin-Code/TestCases/Test_case_msp_read.pdf

[bhunt2]

it should state what the bytes are going to look like. these many bytes and values from 1000-2000 and such. there shouldn't be any ambiguity. On May 16, 2016 11:42 AM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 For read only values like attitude where values depends on what position is the Flight Controller , can I have column that says Expected Total Bytes?

— 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/24#issuecomment-219337501

[bhunt2]

@sabmah @spesialstyrker

The changes I see to the test are looking much better and more defined. There is still some things that can be misunderstood by using different data types in the fields for bytes being sent and received.

Header: $M< (each of these characters are 8-bit char) Length: 16 (this is an 8 bit unsigned integer, not two 8-bit char characters) Code: 200 (this is again an 8 bit unsigned integer, not three 8-bit char characters)

Do you see how these things can be interpreted incorrectly by someone who does not have a good idea of how things work? I understand what it is because I have worked with it, but when you send this to Dr. McNames and Prof. Faust they won't have that background knowledge and will easily be confused by what you are doing.

On the other hand, again this has to with the greater level of ambiguity you had in your previous test, I did not know that you actually had command line arguments for running your tests. Since you have that, you don't need to state anything about the frames. You just need to supply the command line commands and arguments to perform the tests as you have done in this most recent update. This with the expected result is all that is needed. The comments field can be used to state specific information about the pass or fail of that step if needed.

Keep it up, this is looking good and you are on your way to getting it all done.

[sabmah]

@bhunt2 Thanks. I will revise my documents and post them again. I have not implemented the key up and down command line yet for throttle. Can I put it down even though I will implement in down the line?

[bhunt2]

of course, if it is something that will be apart of the system it should be in the tests. On May 16, 2016 4:18 PM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 Thanks. I will revise my documents and post them again. I have not implemented the key up and down command line yet for throttle. Can I put it down even though I will implement in down the line?

— 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/24#issuecomment-219364366

[sabmah]

Hey @bhunt2 , I was wondering if I'm safe to go ahead and test the drone flight from the test plan.

Here is the test plan: https://github.com/bhunt2/QC1.0/wiki/Drone-Control-Test-Plan

I also documented the Automation Code Overview: https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview

I will be adding more to it.

Thanks,

[bhunt2]

@sabmah

This is looking good. Great work over this passed week. I look forward to seeing the test results. Here are my comments about the tests.

MSP_Read Test:

1. Data section in attitude read test has: angx[-1800;1800]/10 pattern for each of the parts of data being received. I believe that you are using the '/10' to show that the data needs to be divided by 10 in order to get the actual value needed. How is your output going to show the data? Is it displaying it as it is received, or is it displaying the value after the '/10' has been processed? This would decide how you state the expected data in this section.

Arm and Disarm Test: Looks good

Throttle Test:

1. How do you measure the spin of the propellers to prove the expected rate? Is this rate, RPMs?
2. What do you mean, 'value of throttle goes up/down when up/down arrow is pressed'? Is the test reading back the value to see if it wrote properly?
3. Since you are having different stages of the test, it may be good to have a color coding for the steps of each stage or something other than just in the setup just to make sure that there is nothing missed or misunderstood.
4. Steps 9 and 10 should include a rate of increase and decrease. You don't want to accidentally set the throttle too high and the drone shoots off. You should slowly increase it while you see when it takes off and see how it balances out after each increase.

Pitch and Throttle Test:

Same as the Throttle test comments.

Once those issues are considered or taken care of then you can continue.

[sabmah]

@bhunt2 Thanks for the response. I will reflect these on the next update.

[sabmah]

@bhunt2 Updated API and Modeling https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview

[bhunt2]

This looks good, but I have some questions. First lets get this answered.

The height is calculated by image processing? On May 19, 2016 11:56 AM, "Sabin Maharjan" notifications@github.com wrote:

@bhunt2 https://github.com/bhunt2 Updated API and Modeling https://github.com/bhunt2/QC1.0/wiki/Automation-Code-Overview

— 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/24#issuecomment-220215591

[sabmah]

@Kekahuna is sending me the height. I think he is actually setting as a constant height in his code

[bhunt2]

you guys need to talk about that. having a constant height will only work if you can hold it at that constant height in your control. does he need the height for his algorithms to work? do you need the height and if so, doesnt the flip have a barometer than can be calibrated for height calculation?

If he is getting height some how, please provide me with a link of how it is being done.

thanks On May 19, 2016 1:09 PM, "Sabin Maharjan" notifications@github.com wrote:

@Kekahuna https://github.com/Kekahuna is sending me the height. I think he is actually setting as a constant height in his code

— 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/24#issuecomment-220223098

[Kekahuna]

The user inputs the height of the object to be tracked at the same time that the user uploads the image to the drone during the initialization stage. My code uses that height to perform the necessary calculations to get the distance of the object to the camera.

[sabmah]

@bhunt2 The height @Kekahuna provided is the height of the object/person (kainoa can confirm on this). I'm using the height value to launch the drone to the provided height. @hau also confirmed that in the test, uploading the image of an object and the object height are both inputs.

[bhunt2]

@Kekahuna @sabmah

Ok, that sounds good. So it isn't a constant height but a value that is entered at the same time an image file is uploaded for the object.

[sabmah]

@bhunt2 I made changes to the test plan with your suggestions. https://github.com/bhunt2/QC1.0/wiki/Drone-Control-Test-Plan

I don't know how to get the propeller rate so I changed the test to avoid knowing that.

I'm stepping up the throttle by 5 on each key press.

[bhunt2]

@sabmah

The setup instructions still states that the yaw, pitch, and roll are going to be set to a minimum value. Hau informed you that this needs to be 1500 for those as it is the mid point for those, in other words, it is zero and above 1500 is positive and below it is negative.

Also, I still do not see any reference to the rate at which you will increase or decrease the values. You have what the increment is, but what is the rate at which you will be making those changes?

So, you will push the up arrow for example every second, or every five seconds. You need to allow enough time for the drone to react according to your command and settle before you change it again. This is not only the safest method, but it allows you to see exact what the results of your choices are. You might find that steps of 5 is too much especially when the drone nears a thrust point that will cause it to continue upward indefinitely.

I believe you can use these initial tests to collect data so that you can determine the appropriate throttle values. Just don't forget that you shouldn't just be hitting the arrow keys without thinking about what the physical result is going to be.

[bhunt2]

Ok, I retract my statement that it is in the kit. I thought I had given you one, but I think I kept it.