Replies to This Discussion

Permalink Reply by Alex S on February 15, 2012 at 2:46pm

That's what should work for the ardupilot. I'm probably getting the Dronecell in the spring, i'll write back here about how it works.

• ▶ Reply

Permalink Reply by Andke on February 25, 2012 at 11:19am

Success.

Today, I did three flights with Dronecell telemetry. 

Currently, APM did not init it, I started the UDP connection using another electronics, then hot-connected it to APM, and flew.

If a competent, good programmer with APM knowledge would help - we could get this integrated into APM.

• ▶ Reply

Permalink Reply by Andke on February 26, 2012 at 1:27pm

ok - who can add code to make APM send some lines of text during boot, to configure Dronecell, before the port is used for telemetry ?

• ▶ Reply

Permalink Reply by Richard on February 26, 2012 at 2:36pm

I was told the mission planer and gsc cannot do two way with udp packets in order. you need to use tcp and a server.

check this out

http://diydrones.ning.com/forum/topics/dronecell-integration-needed...


this is a start and im glad it's going to come together.

• ▶ Reply

Permalink Reply by Andke on February 26, 2012 at 2:39pm

order should not be very important, since MAVLink does contain checksum/integrity verification.

• ▶ Reply

Permalink Reply by Paul Mather on February 26, 2012 at 2:48pm

Order is absolutely critical. Unless lots of re-try logic has been implemented in the GCS sending packets out of order will not work...at all. Checksum does not fix the order in which data is sent and I highly doubt the APM or the GCS have this logic fully implemented. TCP is clearly the right way to go if you want bi-directional data. If it's just flowing from the plane to the ground then UDP will work fine.

• ▶ Reply

Permalink Reply by Andke on February 26, 2012 at 2:51pm

in one packet - one parameter could be set - next packet could ask back a readout of that parameter - unless sent==current,  resend  - VERY simple logic that GCS could easily do,

• ▶ Reply

Permalink Reply by Paul Mather on February 26, 2012 at 2:58pm

You are right. Very simple logic. Very complicated to implement. You'll need to look at the code for the GCS and for the ArduPilot to confirm this has all been implemented or else you're in for a LOT of extra coding. It's incredibly easy to say. It's very complicated to code as you have to add timeouts for everything. Every command that gets sent you have to send it and then start a timer and wait for a reply. If nothing arrives in a pre-defined period of time, then you have to ask again. Then you have to deal with two packets that arrive with the same data since you've now asked twice. Timeouts for every command that's sent, lots of extra coding to handle packets out of order.

 

There is no reason to do it UDP instead of TCP.

• ▶ Reply

Permalink Reply by Andke on February 26, 2012 at 3:22pm

"There is no reason to do it UDP instead of TCP."

Yes, there is.  - GPRS have limited capacity, there's no need to resend all telemetry (position etc) packets all the time - if last position, altitude, heading,battery voltage is lost, no reason to resend it - that information is old already.

Also, TCP connection is more sensitive to really crappy GPRS connection, and takes more packets to establish, while UDP ... just send it...  if you get thru 1 of 3 TCP packets - you lose connection soon, (retransmission will take slow down even more) - if you get thru 1 of 3 UDP packets, you can still see get some information.

Sure - I could make TCP just as easy, but then the Planner should get support to act as an TCP server too, (it's currently only a client)

• ▶ Reply

Permalink Reply by Paul Mather on February 26, 2012 at 6:30pm

Then be prepared. MAVlink is a bi-direction protocol. Packets out of order will most likely be handled poorly and may cause a crash in the program. TCP is the right way to do it. As long as you know you're taking the very real risk of crashing your GCS...and possibly your autopilot....go for it. Your GCS crashes, you re-start it and then the autopilot is possibly bogged down with downloading parameters for the next few minutes? Clearly not worth the risk.

Permalink Reply by Andke on February 27, 2012 at 12:47am

ok, besides criticizing what I did - you did not even check if the APM or GCS does a sanity check for incoming data ?

besides, I log to home - not sending data from GCS to AP - simply because I mostly use it to log - not fly by it - yet.

• ▶ Reply

Permalink Reply by Paul Mather on February 27, 2012 at 5:41am

That's up to you. I'm just pointing out your mistake. Good luck!

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• Next ›
• Page