..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. :)
Then go for it!
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.
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.
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.
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.
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?
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...
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.
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.
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.