Text message telemetry with Dronekit

Jesper Andersen February 4, 2016 at 5:24am

Sounds a lot like what I did a while back in this DIYDrones blog. I used the XMPP protocol to communicate "Human" messages and telemetry from the drone to a computer in the field or a server at home - and natural language messages (like: "go to waypoint2" or "turn on lights") to instruct the drone in what to do.

I've recently started to use dronekit which is super nice and dead easy!

JB February 3, 2016 at 9:03pm

Hey Chambana

The idea originally came when I was looking into the iridium messaging system for the OBC. I see this being a method to also improve normal mavlink telemetry over RF modem like RFD900 etc as well, possibly improving performance when the system is at its limits. Ideally one would use a similar method that MPEG does, in that only data that changes significantly, or is critical to inform the user of the vehicle state are actually sent. I think there is no reason to update the user of things that do not change or are operating according to plan, or a previously learnt or preset profile.

For example whilst it's "interesting" to see accelerometer g-forces or the battery voltage drop by deci-volts it adds no value to the user's situational awareness or ability to respond to a mission critical event. Taken to the extreme this could be condensed to simply "All systems green - on track to WP" message, like a "mission heartbeat" msg, and then follow that up with any vehicle/system/nav state changes as they occur. Once an parameter out of range error occurs then those messages relating to that event can be prioritized and sent. Of course whilst the system is in the "green" other messages can alternatingly use up the message space to give the user updates on individual messages, even of those items that aren't currently critical.

The other item is of course to reduce the resolution of the messages sent. For example battery voltages could be displayed in pre-set levels and the first few digits of lat-lon can be neglected etc as it's unlikely that most UAV's have enough range to change them.

Overall I think in combination these strategies can significantly improve messaging over any type of telemetry pipe.

Let me know how you go implementing them. Are you thinking of doing this on a companion SBC or the PXH itself? Ideally it would actually be done on the PXH, I'm not a big fan of running companion SBC's as primary comms. It also allows a more compact setup.

Regards JB

Chambana February 3, 2016 at 7:38pm

@JB I think there is probably a worthwhile spin-off project in developing a scaled down MAVlink telemetry project -- designed specifically for use over very-low-bandwidth/very-high-latency links. That way it wouldn't be SMS specific, but could be used over a variety of radio/sat links.

And yes, I do think the next step is to more intelligently select what gets sent over the pipe. The SMS's are still dominated by high frequency messages (like ATTITUDE), which are probably unimportant to send over a high latency link like SMS. At this point, the code only really prioritizes the transmission of ACK messages (so that set_mode requests from the GCS will receive feedback) and the code also prioritizes the transmission of HEARTBEAT msgs that contain any state changes. Ideally, I think you'd filter and prioritize a basket of "high priority" messages like GLOBAL_POSITION_INT (your fused EKF position info from GPS and other sensors), SYS_STATUS (which has your battery info), STATUSTEXT, any kind of Failsafe/Geofence messages, and things like that. Maybe even make the basket of high-pri msgs user selectable. In some cases, you might only need to send certain fields from each of those messages, saving additional bytes in your 160 character SMS.

Triggering the transmission of a mavlink message based on its contents is something I haven't done much with, but is a pretty good idea. I do this to some extent with HEARTBEAT messages, but only by checking its contents against a cached copy. What you propose would require, for instance, inspecting each mavlink message coming out the autopilot to see if, for instance, the voltage_battery field in a SYS_STATUS message falls below a specific threshold, but I dig it.

JB February 2, 2016 at 2:01am

Good work Chambana. Your reasoning is sound but is proably limited to places where SMS is cost effective or mobile NAT is blocking access.

I suppose this is also a good way for condensing messages with sat type messaging services that would otherwise be prohibitive cost wise.

Do you have any plans on creating a system that can respond to particular groups of mavlink messages being requested? I'm thinking that most messages can be prioritized by when and how often they needed to be updated, as well as being triggered by a certain event, that makes them momentarily important ie battery low.

Chambana February 1, 2016 at 10:48pm

Hey guys, just saw that my project was posted on DIYdrones! The code is definitely a work-in-progress, but I think I can clarify some of the issues raised in the comments. Also, before I go any further, I should say that I don’t think SMS will ever be the “best" solution for telemetry, but it does have a couple of distinct advantages.

—The primary reason to consider using Text Messaging for telemetry, at least within in the U.S., is simple: Cost. I don’t want to pay for 2 mobile data plans just so that I can have 4G telemetry when I fly/drive my copter/rover once a month. Sure, there are some cheap data plans in the U.S. and I could save some money by temporarily using my personal cellphone’s SIM card for the Ground Station 4G Modem, but nothing will be cheaper than AT&T’s $2/day all-you-can eat SMS plan. You just load up a cheap AT&T SIM with credit and the moment you send your first telemetry text message, you start a 24-hour window with unlimited texting for only 2 bucks.

— SMS also “just works” for sending telemetry modem-to-modem, and it probably does just about anywhere in the world with even 2G GSM coverage. Getting *direct*, 4G-modem to 4G-modem comms isn’t as trivial in the U.S. as it is in Europe and elsewhere. Every U.S. mobile provider that I’ve tried (AT&T, T-Mobile, etc), puts both of the modems on a NAT’d, private subnet and you can’t open a direct socket connection between the 2 modems. One workaround is to open a business account with AT&T/Verizon/etc and then purchase specialized Machine-to-Machine SIM cards with pricier data plans, which will give your modems dynamic, public IPs and allow for direct modem-to-modem communication. This is probably not a great solution for a budget DIYer, but it would work very well if you want to pay for it. Alternatively, you can make use of a 3rd party server (e.g. VPN) to tunnel the traffic between the 2 NAT’d modems. There are free VPNs out there, but you might have to pay for a high speed, reliable VPN —increasing the cost/complexity of 4G telemetry in the U.S. That said, using a VPN for 4G telemetry absolutely works and there are some solutions that make it less painful (I think 4Gmetry is one). People have encountered other nitpicky issues as well when trying to route telemetry over VPN over 4G (e.g. random t-mobile UDP throttling and connection resets), and it seems as though US telecom providers really don’t want their customers using 4G modems as servers.

—Speaking of cost, there is no way I paid $100 for these modems. I just checked and the AT&T 4G momentum (Sierra 313u) is routinely selling on eBay for less than $20 (the project requires 2 of course).

—As for SMS reliability and/or delayed delivery, this is certainly an issue, but one that the MAVlink protocol, to some extent, attempts to mitigate across links that encounter spotty coverage (802.11, 915mhz telem radios). I believe the most prolific MAVlink telemetry messages, such as ATTITUDE, VFR_HUD, or HEARTBEAT, are best-effort and won’t be resent if dropped. However, MAVlink will ACK messages like SET_MODE, albeit very slowly over SMS. MAVlink also uses sequence numbers for packets and, if I’m not mistaken, that may alleviate any issues triggered by delayed delivery of SMS. I can’t say for sure because I never saw delayed delivery of an SMS happen during testing.

—I think @Bill Bonney mentions a key point that I initially struggled with. This project doesn’t attempt to “fly” the aircraft via SMS — that would be insane. The autopilot is flying the aircraft and SMS simply provides the ability to issue updated command-and-control on a circa 1 second delay (e.g. Change Mode to RTL), as well as provide limited telemetry data from the vehicle down to the Ground Station (e.g. transmission of GLOBAL_POSITION_INT messages, battery voltage readings, etc)

— It was an interesting challenge to see how much MAVlink telemetry data I could crush into 160 characters. Instead of compressing full MAVlink messages, you could probably make this project much more efficient by decontructing/reconstructing a targeted basket of mavlink msg types on each end of the link and trimming down the actual data that gets sent over SMS.

—@Khoa Vu, with minimal effort, you could probably tweak the code to accept SMS commands from any number of computers/tablets/phones or even send telemetry down to additional computers. It would be simple to implement, but you’d probably want to add at least some minimal authentication :)

Developer

Tom Pittenger February 1, 2016 at 10:07am

good step toward low-bandwidth mission planning via sat-link

Michael Doornbos February 1, 2016 at 9:26am

I definitely see a use case for me for the UAS to text back to a ground station for my average mission. I'm sure there are lots of uses for a long range non real time message system.

Developer

Bill Bonney February 1, 2016 at 9:05am

@Darius Yeah, I know. I'm ex-Nokian :-p WAP was said as a joke. WAP over SMS isn't any slower than any other technology over SMS.

@JAB if you are on a congested network, I think you can upgrade the connection to a better 2G GPRS or better connection, still going to be slow

@Michael You correct it's a cheap connection with low frequency updates. Another member as been looking at a low bandwidth MAVLink messages for use on satellite phones.

This solution is ideal for non-realtime control of a autonomous robot, the robot is autonomous after all. :-)

Michael Doornbos February 1, 2016 at 8:41am

While maybe not a great production solution at the moment there are probably some use cases and I'm really happy to see people working on this.

Developer

John Arne Birkeland February 1, 2016 at 8:07am

Main problem with SMS is that there is no delivery guarantee. SMS data also have a low priority in networks, resulting in variable delays depending on how much congestion there is.

Blogs

Text message telemetry with Dronekit

Comments