Socket Errors

[Pliskin92]

Hi Stephen.
Sometimes, while the Drone is Flying, the drone disconnects from the program giving more than one socket error, and the biggest problem is that I cannot connect to the drone without exiting the program and launching it again. Why does the Drone give me an error like this?This is a big problem, especially when flying at an height of 20 meters.
Thanks in advance,
Mattia

[AndersMalmgren]

Try to increase the timeout time, the default 500 ms is sometimes exeeded

[Pliskin92]

I thought about this, yeah it could be. I'll try today and I hope it works. I had to increase also the ping timeout because 50% of times I start the app it crashes for ping error. Thank you very much!

[Pliskin92]

It seems quite working, but there's another problem, could it be that when I receive a call from my phone that the software retrieve a socket error?

[shtejv]

Hi Pliskin ... The network code still seems to be a bit fragile ... so when there are other strong signals, it seems to break down. That's a huge problem that I also encountered when giving the presentation.

Btw. Stephen doesn't work for this project anymore. I'm Thomas :-)

[Pliskin92]

Oh, sorry Thomas :)
Thanks for the reply.
So, what could we do about this?Rewrite totally the Network classes? Any suggest?

[AndersMalmgren]

Very strange, works perfect for me with the timeout fix, here's a youtube clip I just did to prove it.
Its a p264 test, I use a low bitrate for test purpose, the picture can get way better than this, as you can see I lose tons of packets but connection stays up. Its my own frontend, but in the backend its the same .NET SDK (Except for the new codec offcourse)

http://www.youtube.com/watch?v=LtLUbFGz8Hw&hd=1

[Pliskin92]

Well probably the problem is because I used the mobile phone while the Drone was flying. By the way, I can't wait for the new release of the .Net Sdk. You're doing a great job. I noticed that VZ is always zero, but not only in .net... And the configuration of the drone is unaccessible for me, and I don't know why... Do you have also this problem or it is only mine?
You made a great video, probably the next sdk release will be quite perfect :)

[AndersMalmgren]

Yupp, mine vz is reporting zero too.
I have a problem right now with multicfiguration, some settings does not work... Will have to fix that before i can have a release ready

[AndersMalmgren]

Ok, my fork is updated with 1.7.4 support, please try and see if it works before I do a pull request to the master

[Pliskin92]

I made something funny for vz... Waiting for a happy new release, I made a DispatcherTimer with a timer every second that checks the altitude of the second before and simply calculates the speed in m/s in this way: altitude 1 second before - altitude now... it works, it's stupid, horrible, disgusting...But it works. Ahahah :) What do we have to try Anders?I don't understand, sorry

[AndersMalmgren]

Try my fork, i dont want to push it to the master until everythiing checks out

https://github.com/AndersMalmgren/ARDrone-Control-.NET

[Pliskin92]

Ok, let's test if it is very good as I am expecting :)

[Pliskin92]

I get the same video errors in Stream.Addframe... But about the video that I made I think I don't have the right codecs, because I checked "use p264 codec". Anyway, the HUD is more efficient and sometimes, even the Drone seems to lose connection (the image freezes for sometimes 2 seconds) the connection remains stable.
About the video, can you give me a place to find the same codecs you have used?
I want to try if it is only mine problem or about the program ( i think it's only mine btw)

[AndersMalmgren]

The codec is included in the sourcecode, so it should work.. Please give me the error message

[Pliskin92]

I did not check the checkbox "Compress Video", I made the video but if I open it it says "Windows Media Player: problema durante la riproduzione del file."in italian, so in English is "Windows Media Player: problem while playing the file.". It seems like a codec error.
The other problem is the exception in Stream.AddFrame, it says that probably memory is corrupt or somethin else, but I did not record lots of videos so I don't know more about that

[AndersMalmgren]

Ah, video recording, that has never worked for me, i thought you didnt get any video at all. Thomas knows more about that, I do not use the SDK client my self so i know very little of it

[Pliskin92]

Yeah, video recording. It's not very important, btw, cause I can put a minicam on the Drone and it works better than the Drone itself.
Anyway the connection seems more reliable with your Sdk. I didn't test the drone configuration...You'll have to wait until monday to hear news from this because my drone unfortunately is not in my house

[AndersMalmgren]

Keep in mind that the SDK default is still 500 ms, you need to increase this yourself.. i use int.MaxValue myself

[Pliskin92]

Ok, thanks very much for your kind help :)

[AndersMalmgren]

int.MaxValue was no great idea btw, it threats that like 0 :P
I went back with 60000 (60 seconds and all is well)

I flew long and high today with the .NET SDK and no problem (Lost some packets and didnt lose connection)

http://www.youtube.com/watch?v=Gc7PWcSW_WA&hd=1

[Pliskin92]

Ahahah, ok that's a good point.

[shtejv]

@anders:
Why did you use Managed C++ for your codec implementation? While this is a valid approach, I don't like mixing programming languages. I think that it will be problematic for future maintenance tasks.
Since you already used Managed C++, it shouldn't be that much of a problem to convert the code to C#.

Since I still don't have much time atm, I cannot help much within the next weeks, I'm sorry.

[AndersMalmgren]

It was just a matter of compiling the code, with some minor changes, a port is much more work. Plus C# isnt very fast at bit manipulation, the C code only takes 0-2% on a modern CPU, while the .NET port took almost an entire core.
I'm actually thinking about doing the same with the entire c SDK since we have problems with the network code in the .NET SDK.

[shtejv]

OK, performance is an important issue here. But I didn't really like the old code. It was sooo damn difficult to figure out why something went wrong ... That was the reason why I switched to a C# only solution.

If we revert this, I will again get a lot of requests where I can't find an answer ...

It would be nice to do a complete rewrite of the old C++ code in C++, so you can actually figure out what is going on in the code.

[AndersMalmgren]

I have no problem rolling with the .NET SDK but we really have to fix the socket problem, I almost had a fly away the other day. The .NET sdk crashed and it was too windy for the hover to work so it started drifting, pure luck a dog lady saw the crash site and alerted me were to look.

The crash is in the Send method of the UdpWorker..

I will ty this code to see if it can help, but Im fumbling in the dark here, just try and error.'

    public override void SendMessage(byte[] message)
    {
        try
        {
            client.Send(message, message.Length, endpoint);
        }
        catch (Exception e)
        {
            Log.Instance.Error(e, "SendMessage");
            Disconnect();
            Connect();
        }
    }

[shtejv]

OK, thanks for the update. I know that the .NET version is not very stable, but I had so much problems understanding what the C++ version did that I did not want to use this piece of code anymore ...