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]

WIKI : https://github.com/bhunt2/QC1.0/wiki/Flight-Automation-Overview

Tests: https://github.com/bhunt2/QC1.0/wiki/Flight-Automation-Overview#tests . There are lots of commands but I only want to test couple for now. Those commands have already been documented here http://www.multiwii.com/wiki/index.php?title=Multiwii_Serial_Protocol in details.

My Code : https://github.com/bhunt2/QC1.0/blob/master/Sabin-Code/sendCmdConverted.cpp
The code has lots of comments and not pretty. I want to get it working before I refactor and make it "pretty". Lots of hard coded variable and values are used. For testing purposes, I have this bare bone as possible.

[sabmah]

Output 1 (with ground wire connected):https://github.com/bhunt2/QC1.0/blob/master/Sabin-Code/Capture_with_ground.PNG

Output 2 (without ground wire connected):https://github.com/bhunt2/QC1.0/blob/master/Sabin-Code/Capture_without_ground.PNG

I do not see any headers "$M<" with ground wire connected. There are no "frame" or patterns. It looks like bunch of garbage data.

For ground wire not connected, I just get back what I send.

Also, When Flight controller has no power (no power to drone), when I sent the commands, I get the same outputs back like I stated above.

UART info: UART @ dev/ttyMFD1. 115200 baudrate .

[sabmah]

I can see header now on the jumbled data. Still don't have any structure as expected.

[bhunt2]

Sabin, this output is looking better than what I was seeing before. Please add a print out of the command being sent such as: "Sending 100" or something like that so it is understand what the response is for.

In the two images you posted above, the second one is with ground unattached/the power is off on the Flip. The first image is with the ground attached and what seems like some kind of response from the Flip, but it is unclear if it means anything. If I read your code correctly, you are only sending one command that is hard-coded into the code and then running an infinite while loop while you wait for a response. If you are only sending one command that has a specific return size and type, why does it seem like you are getting back way more than you should be? Again, I don't know which command/request this picture is issuing to get this response so it is difficult for me to determine anything from this. From the looks of it, the first several bytes that come through are an appropriate response. We just don't know what the rest is.

Also, please load the data received into a struct that stores the data in its appropriate frame. This will facilitate much faster debugging and clear outputs. Do you have everything connected so that I would be able to run your code myself and see what is happening?

[sabmah]

Yea, you can run my code . it is under @root Drone/drone.cpp (this is my old code).
@root Drone/drone1.cpp is the refactored version. it has struct datatypes for each test commands.
The only thing is Drone needs to be turned on and battery doesn't last that long . I have to recharge it constantly.
So, testing is difficult remotely.

[bhunt2]

I thought you had these connected and powered via USB right now while are figuring this stuff out. Especially while the drone cannot be flown, there is no reason why the two boards can't be connected by wall power or something else that doesn't need to be charged. Right now we need as much access to the Edison, Flip, and camera as possible to accomplish the current tasks.

[bhunt2]

Also, thanks for the update on where your code is and that it is ok for me to run it. Please answer the other questions I had in regards to what we are seeing and update the documentation to show the new outputs. We can figure this out quick if we work together on it.

[bhunt2]

I think I figured out why you have to use the drone to power, it is because the USB is not repaired yet. Correct?

[sabmah]

Yes, I was trying to connect the Flip with USB adapter and that's when it broke. Hau will pick it up Monday and fix it soon as possible because my tasks depends on Flip.
I still don't know What I'm seeing on the outputs. I'm looking online to see if I miss anything. I will update if any new output comes out. Thanks!

[bhunt2]

What is the plan for getting the system back online for us to begin working on this again? I know that a few things need to be fixed, but hopefully in a day or two right?

[sabmah]

Yes, I'm hoping Hau gets it fixed quickly so that I can work on it.

[sabmah]

@bhunt2 @spesialstyrker @hautruong36 @Kekahuna
I have been having problems on communicating with Flip MWC 1.5 as I have stated in this issue #24
I researched the specs on FLIP MWC FLIGHT CONTROLLER 1.5 and found out that the there is only one serial port for Bluetooth.
Does this mean this is only used for Bluetooth protocols? I am hooking my tx/rx pins from Edison to the Flip's serial port.
Also, I looked through their firmware code, it looks like its listening to the USB port.

[bhunt2]

@sabmah

What happened to your comments that were in issue #27? Your comments were important in and of themselves. They also help in understanding why I wrote my comments. Also, I am still waiting on answers to some of my earlier questions. Please provide you input as soon as possible.

[sabmah]

Oh! I thought you meant just copy your comment over. I'll re post all threads here from #27

[sabmah]

I found this global constant on https://github.com/sabmah/multiwii/blob/master/MultiWii_shared/config.h#L708 but it was on the GPS section of the code.

//Enables the MSP_WP command set , which is used by WinGUI for displaying an setting up navigation
 //#define USE_MSP_WP

[sabmah]

@sabmah @Kekahuna @hautruong36

This should not be in a new issue. It is just more discussion about the same issue. Please move this information to issue #24 and we will continue the discussion there. I will put my comments in regards to these concerns here, so please move them with it so everything stays in order. Once it is moved close this issue.

My comments to be copied:

Bluetooth UART: First of all, what bluetooth is the Flip trying to work with. There is no reference to BT in the firmware or documentation and nothing about it in the description of its capabilities. There is a reference saying that you can connect a BT device, but it is an optional device. The only device I see that is using serial by default is GPS. The GPS also can be configured to use I2C. Since at this point you will not be connecting it, you can find out in the firmware or in the multiwii software how to disable it. The additional data being transferred that we saw in a couple of your screen shots that didn't make sense may have been the Flip trying to communicate with the GPS. I am not sure because I haven't looked that thoroughly through the code.

Firmware is listening to USB port: ATmega328 only has one serial port available. This means that it will be used for both USB and other device communications. This may be the other possible reason why we see erroneous data in the output. I have not looked at everything so I don't know all the protocol and exactly how it is connected, but there may be some other setup needed to communicate properly. Remember you chose a different path than I had, so we are all learning together here.

Communication with the Flip: Remember, the Flip allows for SPI, I2C, and UART communication. Any one of these should have the libraries available for the Edison. They are pretty straight forward methods of communication, so it shouldn't be too much to get something going with any one of them.

For determining proper communications:
Serial - You can use Putty setup to the appropriate port and speed to see what is being transmitted.
I2C/SPI - There are two of the logic analyzers in the Willow Creek lab that have decoders that can tell you if the protocol is correct and tell you what the data is that is being sent in real-time.

[sabmah]

These are the following things I found:

• No SPI on Flip MWC 1.5
• I2C on FLip MWC 1.5 does not support MultiWii Serial Protocol

[sabmah]

I've recorded an attitude output. It is running on python code.
https://youtu.be/chRzSkRgi4Y

[bhunt2]

@sabmah

That looks good. Is this the code that you found in Python and just decided to try it out as is? I only see the Flip1.5 in the video, but it is connected to the Edison sitting on your desk or something right?

Please post information about what you did and how it worked and add the code to the repository. Also, updated Taiga appropriately. Then, please provide your plans for moving forward with this issue as we still need to test all commands and decide how to integrate with everything else. Are you going to stick with this Python code or will you be converting it to C++?

[sabmah]

@bhunt2 @spesialstyrker @Kekahuna

Yes, I used the python code that I found before (https://github.com/alduxvm/pyMultiWii).
The Edison is out of frame on video but it is connected to Edison.

The C++ code that I have wrote is about the same except I used mraa library while python just using pyserial library.

On python code, struct.pack and struct.unpack for packet conversions.
On my c++ code, I'm casting for packet conversions. I'm suspecting if type conversions are the cause.

kainoa's image processing is on c++. That's why I went with c++. Python is much easier to use with their awesome libraries and if I use python, I might have to tell kai to write his code on python or use some other method to communicate with kainoa's c++ code.

I will update the plans on my wiki but here is brief:

• Check with kainoa on receiving data from image processing
• decide on python or c++ for both image processing and serial communication
• Write Arm and Disarm code for the drone. This is done with MSP_SET_RAW_RC command

[bhunt2]

@sabmah @Kekahuna @hautruong36 @spesialstyrker

I think that it is totally unreasonable to have Kainoa switch his code just to make your task easier. It would take far more time for him to port all of his work to Python than it would for you to debug your code. Also, communicating between programs would take processing power that you don't want to waste so that really isn't an option. It is possible to write C/C++ wrappers to extend Python code but I don't think that is a good option here either especially because you don't have much experience with either.

I would like to try and help but with the current circumstances it is difficult because I don't know when the Edison is connected to the Flip. If you guys can work out a schedule to know when things are going to be connected then we can try things out. If you need help with anything specific that would be easier to have someone beside you, I am sure Michael would be happy to work through it with you.

In regards to your plans to write Arm and Disarm code for the drone, that really isn't something you should be thinking of yet and doesn't follow the given stories as we have discussed. You must first complete the basic code that establishes communication. Then, develop a test that will ensure that all communications that will be needed for drone flight works and run the test. Then, think about Arm and Disarm code. If you need Arm and Disarm code for the final testing, then you would want to add that into your test plan as a necessary element to be written. Otherwise, it can wait until after testing.

[sabmah]

Flip is always connected to Edison and Kainoa has it at this moment.
We can try debugging the C++ Code like you said. I don't know if michael @spesialstyrker has looked at the code and would be helpful if I get any comment on the code.

I said Arm and Disarm because, it would be part of the next command I was going to test -MSP_SET_RAW_RC. I can just isolate the test to just test that one command.

[bhunt2]

Ok, if you need to do the arm and disarm code it is fine. If you can write the test plan with notes as to why you will test the way you are and how you will move forward with it that would be great. Michael @spesialstyrker and I will try to see what we can find in your code. Please update your Wiki to tell us what code we should be looking at and how it is suppose to work (pseudo code unless the pseudo code for your algorithm is already in the code).

[sabmah]

@spesialstyrker @bhunt2
This is the pseudo code. I have link to my code in the wiki.
https://github.com/bhunt2/QC1.0/wiki/Flight-Automation-Overview#test-code-algorithmflow

On Edison itself, it is located @root/Drone/drone.cpp

[bhunt2]

@sabmah @Kekahuna @hautruong36

Please provide the settings for connecting to the Edison. Now that Kainoa has it, the IP has changed. Maybe you could have a wiki page for the connection information and instructions on how to do it.

[sabmah]

@bhunt2 @spesialstyrker @hautruong36 @Kekahuna
Here are the ssh information for edison : https://github.com/bhunt2/QC1.0/wiki/Edison-SSH

[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
#24 (comment)

[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 #24.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#24 (comment)

[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
#24 (comment)

[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
#24 (comment)

[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
#24 (comment)

[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
#24 (comment)

[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.