-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various changes #34
Various changes #34
Conversation
Also reorganized the code to be more readable.
…ll need to add support for writing them.
Also removed redundant code in QGCMapWidget.cc.
…ibraries to the /debug and /release directories based on which is currently building. These copies are also only done if they are necessary. I removed copying of the plugins folder from Qt to the executable directory as I don't believe it's necessary anymore.
… debug within it. Nothing major, though I did remove an unnecessary loop.
… accept messages addressed to the MAV_ID_MISSIONPLANNER component. This was causing problems with the send-loss value being calculated, so I decided to add this until a proper solution can be developed.
Changed the drop rate from a SYS_STATUS message to follow the MAVLink specs along with some extra range checking.
Conflicts: qgroundcontrol.pri src/uas/UAS.cc
Highly appreciated, all merged in. The hardcoded component ID in mission / waypoint handling has been identified and is currently work is done to resolve it properly. Your immediate fix is the right thing in the meantime though. https://github.com/Trof/qgroundcontrol-1/tree/no-osg On Feb 15, 2012, at 8:39 PM, Susurrus wrote:
Lorenz Meier |
int16_t lostMessages = message.seq - expectedIndex; | ||
if (lostMessages < 0) | ||
{ | ||
lostMessages += 256; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi!
This piece of code causes huge problems with out-of-order packets, which may occur when using UDP via some intermediate network nodes. We are facing serious loss rate peaks (up to 30%) each time a message is out-of-order, like in the sequence [2,1]. In this example we expect after 3 to be the next seq number, but we get 1, so lostMessages = -2. The if yields lostMessages = 254.. which is quite a lot!
Accoding to http://www.wireshark.org/lists/wireshark-users/201112/msg00030.html, wireshark calculates packet loss via (SEQ_N - SEQ_N-1 - 1) in RTP, which is exactly the same as lostMessages = message.seq - expectedIndex in your code. The difference is that they allow this value to be negative.
So maybe one solution would be to remove the "if" or just set lostMessages to 0 instead of 256.
Regards,
Tobias
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you prototype this solution?
I'm aware of several pull requests you have issued, please merge in the code from master however first. I'm happy to mere it in, up until now it creates however merge conflicts for which I need substantially more time to resolve and then validate. If you handle this, I can merge faster.
--- Ursprüngl. Mitteilung ---
Von:Tobias Simon
Gesendet: 18-02-2012, 09:27
An: Meier Lorenz
Betreff:Re: [qgroundcontrol] Various changes (#34)
// while (lastCompIndex->value(message.compid, 0)+1 )
// }
//if ()
// NOTE: Using uint8_t here auto-wraps the number around to 0.
expectedIndex = lastIndex[message.sysid][message.compid] + 1;
}
// Make some noise if a message was skipped
//qDebug() << "SYSID" << message.sysid << "COMPID" << message.compid << "MSGID" << message.msgid << "EXPECTED INDEX:" << expectedIndex << "SEQ" << message.seq;
if (message.seq != expectedIndex)
{
// Determine how many messages were skipped accounting for 0-wraparound
int16_t lostMessages = message.seq - expectedIndex;
if (lostMessages < 0)
{
lostMessages += 256;
Hi!
This piece of code causes huge problems with out-of-order packets, which may occur when using UDP via some intermediate network nodes. We are facing serious loss rate peaks (up to 30%) each time a message is out-of-order, like in the sequence [2,1]. In this example we expect after 3 to be the next seq number, but we get 1, so lostMessages = -2. The if yields lostMessages = 254.. which is quite a lot!
Accoding to http://www.wireshark.org/lists/wireshark-users/201112/msg00030.html, wireshark calculates packet loss via (SEQ_N - SEQ_N-1 - 1), which is exactly the same as lostMessages = message.seq - expectedIndex in your code. The difference is that they allow this value to be negative.
So maybe one solution would be to remove the "if" or just set lostMessages to 0 instead of 256.
Regards,
Tobias
Reply to this email directly or view it on GitHub:
https://github.com/mavlink/qgroundcontrol/pull/34/files#r464652
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks for the info. I'll close the broken pull requests and send a cumulative one with your master merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's a bunch of improvements that I've made. Most of these are related to Windows compilation and new autopilot integration.