Replies to This Discussion

Permalink Reply by Andke on February 27, 2012 at 5:44am

..as long we all remeber that both qgroundcontrol, and Ardupilot Planner made the same "mistake" of using UDP as well. :)  - and in case of qgroundcontrol - there's not aven an option for TCP.

I'll tell you if it proves you had a point here. :)

• ▶ Reply

Permalink Reply by Paul Mather on February 27, 2012 at 6:25am

Then go for it!

• ▶ Reply

Permalink Reply by Alex S on February 27, 2012 at 6:30am

Thanks for giving us an update, and please keep us posted with any news you have.

I'm getting the Dronecell soon too, and i'm inclined to also go the UDP route, since i'm more interested in following the drone and logging the data in realtime than doing two way live communication through mavlink on TCP. 

• ▶ Reply

Permalink Reply by Blake Turner on February 27, 2012 at 12:42pm

Having extensive experience developing communication and telemetry systems on cellular technology, I would agree with Paul. Simply put, if you want _reliable_ bi-directional comms, TCP is your answer. If you are only interested in a telemetry stream, then UDP is your answer. While you can communicate bi-directional over UDP (got multiple T-shirts), its not worth the overhead on the hardware we have at our disposal today.

Yes, it can be done. Is it the best way to do it, no.

• ▶ Reply

Permalink Reply by Andke on February 27, 2012 at 12:45pm

ok, for my part - telemetry is main goal for now, - I also know that reliable communication can be done over UDP - provided that we have software to verify/retry when needed. 

TCP is just a small step away - basically we need to handle reconnection, and GCS should be able to behave as TCP server.  - both should be easy to overcome.

• ▶ Reply

Permalink Reply by Paul Mather on February 27, 2012 at 12:54pm

For telemetry it should work fine. I would not recommend uploading any missions or changing any parameters. I also don't know if the planner or qGroundControl request all the info on startup. I know my GCS does with APM. This would be bad mid-flight if you had to re-connect UDP. TCP, not so much but still might be too much processing time spent on parsing communications and not enough on flying the plane.

• ▶ Reply

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

ok - I just solved the TCP "challenge"

TCP connection is not a problem - Dronecell boots, commands gets it's IP - IP is SMS'ed to my cellphone - I enter it into GCS and connect to it.

drawback by connecting TO dronecell;  you need a carrier that offers an alternate APN without "firewall" - mine does have such APN.

• ▶ Reply

Permalink Reply by Blake Turner on February 27, 2012 at 1:05pm

Hence my comment regards overhead. In my honest opinion, while you can do some really funky stuff with the DroneCell integration, I think its intended purpose was primarily as a telemetry channel, not a control channel. If you want proper GSM based control, use a phone module that has a TTL serial interface and internal application space that you can load an application on the phone module to run independant of the APM. All comms and control is handled there and becomes much like an Xbee, just over the cell network. I'd guess an Arduino Pro Mini + DroneCell may do the trick then connect the pair to the APM via the serial interface ... just maybe?

• ▶ Reply

Permalink Reply by Richard on February 27, 2012 at 1:31pm

I agree with Paul and Blake...

As it stands, the only real benefit for this dronecell is the fact that you can indeed connect it to UDP or TCP/IP and the like... The only other benefit is that you can use dronecell with a network via towers on a GMS network and this will allow you to fly farther and higher (laws provided, laws say can only go 300' or 300 meters high I know there is a difference between the conversions but I'm not sure if it were 300' or 300 meters)... The other thing is if you are to connect it using TCP/IP you can use two-telemetry to send and receive data... You can also then send commands via web browser or cell phone or any other connection device... This is where dronecell will excel past xbee and actually be a benefit to users...

• ▶ Reply

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

regarding microcontroller overhead, and some of the comments here - remember that I do transparent connections, once the GSM module is initialised - it seems transparent - APM does not need to spend more time on it other than the config after boot.

• ▶ Reply

Permalink Reply by Blake Turner on February 27, 2012 at 1:53pm

Andke, UDP packet management would be the responsibility of the APM, specifically when attempting to use UDP for bi-directional comms, which is where I was referring to overhead. TCP stream management, in this case, is done by the DroneCell, hence our recommending TCP. However, should TCP (and even worse with a UDP) connection be lost mid-way through a mission upload or similar, there could be a large amount of APM overhead re-synchronising the connection state.

• ▶ Reply

Permalink Reply by Andke on February 27, 2012 at 3:00pm

Blake : exactly - I basically wrote the same xx posts earlier, when I suddenly needed to "defend" UDP  when it got described as a useless choice.

• ▶ Reply

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