Testing the dronecell or other GSM modem

In this page you will find information about testing and using the dronecell or another GSM modem with APM's new AP_Modem library

The current code is still in early development, is buggy and requires some experience to compile and deploy. But, it works and it allows telemetry to flow over TCP or UDP anywhere around the world, directly from your drone!

Requirements:

- APM1 or APM2 can be used. The code is different slightly, so test each separately

- A dronecell or any other AT-command compatible modem

- A data-plan SIM card

- (Optional) Dynamic DNS or fixed IP for convenience

Skills: You will need to be able to compile the ardupilot-mega code from source and install it on the hardware. 

1 Getting the hardware



If you do not have a dronecell, you can try buying one online from diydrones or another store. You might find it difficult to source one. 

Other than the dronecell, you could try another GSM module. The closest is the Arduino GSM shield sold on Amazon which includes a SIM900 GSM module, which is the same brand as the dronecell modem. 

The code should work for any GSM modem that supports AT commands. The only changes would be in the init_script. If you are brave, try another type of GSM/GPRS modem.

SIM Card: Need a compatible GSM network. I personally use the T-Mobile pre-paid SIM card with $2 per day cost (for any day it is tuned on) and up to 200MB of data. It cost me only $10 to buy, all cash, no contract, no names, no addresses ;-)

2. Getting the software [UPDATED x 2]

The software is available as a new branch of the code, based on ArduCopter2.6 and ArduPlane2.4. (ie, the current master branch).

Using GIT

If you are familiar with git, you can pull the modem_test branch from google and compile it, from here:

 http://code.google.com/r/andreas-apm2-wip/source/checkout

You will need to checkout the modem_test branch

git checkout modem_test

then compile and install

Download a pre-compiled HEX file to flash

ArduCopter 2.6

Downloading Manually  [ This approach is no longer practical ]

3. Preparing the hardware

The dronecell comes with a default speed of 38400. Other modems may be set to 9600, or any other speed. The APM1 telemetry port is at 57600. So the two must match. You have three options:

a) Change SERIAL3_BAUD to 38400  in ardupilot code. My libraries respect whatever you set and will work with it. Then the dronecell will work. But xbees won't. So you will have to swap the speed in the code back and forth between 38400 and 57600 to use other radios.


b) A better option is to set the dronecell to 57600 permanently. Connect to dronecell serial to a serial2USB (FTDI) cable a terminal (the one in Arduino IDE will do) and change it to 57600. If you don't have an FTDI cable, you can slave the modem to any Arduino board by connecting it to TX0 and RX0 and then running an empty script ("Basic" in ArduinoIDE). 

Commands are:

AT+IPR=57600

changes speed to 57600

AT&W

writes the change to memory permanently.

c) If option (b) is too complex, then you can also do the following... do (a) to have APM able to speak to the dronecell at 38400. Then change the init_script (in Cellular_Modem.cpp) and add the following in the fifth or sixth line (doesn't matter really exactly where, just after the initial 4 commands):

"AT+IPR=57600",

"AT&W",

That will have the APM tell the dronecell to switch baud rates. The rest of the script will fail (APM is still trying to talk 38400 at this point, but the dronecell is now listening at 57600). Change the SERIAL3_BAUD back to 57600, and now dronecell (and everything else) speak 57600. 


4) Configuring the Software


You will need to make changes to the settings to reflect your SIM card provider


Open AP_Modem.h and find these lines:


#define VAL_APN         "internet" // value for the APN
#define VAL_USER        "" // value for the user name
#define VAL_PW          ""      // value for the password


The settings above are the ones that worked for the T-mobile SIM card. Most SIM cards no longer use a "username" and "password" to log onto the data network, so those usually remain blank. The APN is carrier specific, though many use "internet" as the APN, so try that.

 

Once you've made the changes, compile and install the code.


5. Connecting the modem


You will need to connect the modem to the telemetry port. Look at the instructions for Xbee, and see where the telemetry port is on your board. If you already use Xbee, this is easy ;-)


Connect RX, TX and GND to the modem. I can't remember if it is TX->TX or TX->RX, but if the modem isn't responding, try switching around. Having an FTDI cable to troubleshoot or an extra Arduino will help a lot.


IMPORTANT - POWER CONSIDERATION:

A GSM modem will draw up to 2.0-2.5A in bursts when transmitting. You cannot power it from the APM. You probably cannot power it from an ESC BEC, though you could try. I power it from a 10A rated BEC (Castle BEC). You can also use a separate battery and BEC to power it. Whatever you do, you need to meet two requirements:


1) provide at least 2.5A clean power at 5V

2) power modem and APM from same power*


* They must share a GND for the TTL to work. If you have two power sources and share a GND, you may create a weird path through your board from one power source to the other. *ZAP*. Easier to run both off a sufficiently strong BEC or battery.

 

6. Set the parameters [NEW]

 

 

MDM_BLIND 1.000000 -- Set to 1, to dial blindly. Set to 0 to validate the modem response


MDM_DEBUG 0.000000 -- Set to 1 for debug messages on the console 


MDM_ENABLED 1.000000 - Enable


MDM_IP1 192.000000  - First byte of IP address
MDM_IP2 168.000000 - Second byte of IP address
MDM_IP3 0.000000
MDM_IP4 161.000000 - Fourth byte...


MDM_PORT 14550.000000  - Port number 


MDM_PROTO 0.000000 - Protocol - UDP=0, TCP=1


MDM_RATE 115.000000 - Serial speed - short form (1=1024,2,4,9,19,38,57,115=115200)


MDM_SERIAL 3.000000 - Serial port (0 is Serial/console, 3 is Serial3/telemetry)


MDM_STATE 0.000000 - Don't change, used to see what state we're in

7. Setup the GCS


The GCS will need to connect to the Internet with a public IP address and the ability to receive traffic on UDP/14550 (or if you changed that, whatever you set). The IP address must be fixed or have a dynamic DNS name, or you will have to set it in the code each time you re-connect. I use a dynamic DNS for convenience. For testing, a fixed IP will work fine. 

Make sure the port is open on any firewalls or gateways and the traffic can get through. 

With Mission Planner, you will set it to UDP and to listen on port 14550.

8. Start the APM

If you are connected on the USB, you will see the modem initialization in ridiculous line-by-line detail (if debug is on). It looks like this:


Init ArduCopter V2.6-modem

Free RAM: 4096
FW Ver: 118
----------------------------------------


load_all took 67us

--MODEM starting on Serial 3 @ 115200 baud
Press ENTER 3 times for CLI

GSTABILIZE> Mode STABILIZE
ublox update:35: gps read timeout 3662 0
OK

GPS
----------------------------------------
enabled

9. Success (??)

If all goes well, here's what should happen:

- Your APM starts up

- The APM sends the init script to the modem

- The modem establishes an Internet link and then start copying traffic (bridging) over UDP or TCP. 

- The APM sends Telemetry data, once it is done initializing. 

- The telemetry data flows through the modem, across the Internet and to the UDP port. This takes about 30sec to a minute to start arriving the first time. 

Wait for a bit for the flow to start, then start MP and tell it to listen on UDP 14550. If all goes well, it will say "Getting parameters" and then connect in the usual way.

You will notice about a 2 second "lag" between activity on the drone and activity on the GCS. You move the drone, the horizon moves on the GCS two seconds later. That is because of the latency introduced by the Internet routers. It can be optimized (and will), but will always be a bit lagged compared to line-of-sight speed-of-light radios. However, despite the latency, the system is not losing packets at 57600 and the flow is consistent and good. So except for joystick flying, you can do your mission planning, PID tuning and such easily over IP.

Comments, questions or support requests below. 

Comment

You need to be a member of Telemetry over cellular IP to add comments!


Developer
Comment by Andreas M. Antonopoulos on June 27, 2012 at 2:26pm

Veikko,

We have the option of setting it up in reverse, where the GCS "calls" the DroneCell. So if the SIM card in your Dronecell does allow incoming but your 3G modem does not, we can set the code up to make the Dronecell the server and the GCS the client (reversing the connection)

Comment by Tommy Larsen on June 27, 2012 at 2:25pm

I had the same problem. All i did was to call my cell provider and told them that i had problems with a VPN connection. Then they reluctantly told me about another APN that had no blocking for incoming connections(required for VPN). Changed to the new APN and, voila!

If they do not have another open APN, it will work if you set the APM as server and your GCS as a client.


Developer
Comment by Andreas M. Antonopoulos on June 27, 2012 at 2:14pm

Veikko,

Is *all* incoming data blocked by the mobile operator? Are you sure you can't use a different port number that will work?

Here in the US I use a cheap pre-paid data plan SIM from T-Mobile in the DroneCell. They do not block incoming ports. 

Is the SIM in your DroneCell also blocking incoming? If not, then you could set it up so that Dronecell is "server", and GCS is client (so connection is started from your laptop to the dronecell, instead of droncell->laptop). But if the mobile operator you use on Dronecell also blocks ports, this will not work. 


Developer
Comment by Andreas M. Antonopoulos on June 21, 2012 at 12:21pm

The new version of the software for modem support is ready. 

Changes include:

- Library has been renamed to AP_Modem (branch modem_test )

- Major changes to the entire initialization system - now happens during the "slow loop", after ground start. This ensures it doesn't "freeze" the board. Should work on both APM1 and APM2.

- Almost all settings are now MAVLink parameters. No need to change the code for most cases. 

- Parameter list example would initialize a modem on Serial3, at 115kbps, forwarding UDP, to 192.168.0.161:

MDM_BLIND 1.000000
MDM_DEBUG 0.000000
MDM_ENABLED 1.000000
MDM_IP1 192.000000
MDM_IP2 168.000000
MDM_IP3 0.000000
MDM_IP4 161.000000
MDM_PORT 14550.000000
MDM_PROTO 0.000000
MDM_RATE 115.000000
MDM_SERIAL 3.000000
MDM_STATE 0.000000

Comments and questions welcome. I will be updating the instructions above...


Developer
Comment by Andreas M. Antonopoulos on June 8, 2012 at 10:12pm

Devin,

The hold up was the refactoring of the geofence library, which is now released for testing and slated for an upcoming release of the code. I'm also working on two other projects behind the scenes (the autobuild and autotest system), preparing a quadcopter build workshop, a developers guided tour webinar and...

I also have a day job to pay the bills and buy the toys  ;-)

The good news is that once I closed the geofence/AP_Limits review code, I started working on the Cellular Modem library. That was 3 days ago. I've now added MAVlink parameter support and I'm trying to find the bug in the startup code. I expect to have something for testing in a matter of days, less than a week. 

Comment by Devin Johnson-Kinlaw on June 8, 2012 at 10:05pm

Andreas, may I ask what the hold up is with DroneCell code debugging? I'm willing to get onboard if you have any recent updates on the improving code, for APM2.0 especially.

Thanks_

Comment by Murray Spoelstra on May 31, 2012 at 2:48pm

The code didn't work on my APM1 with Arducopter 2.6 beta, but it compiled using 2.5.5 after manually doing the changes in Arducopter.pde and System.pde. I'm trying to connect a Seeeduino Sim900, but haven't had success yet.

Comment by Asaak on May 31, 2012 at 1:48am

Is the code still broken??

I am really looking for testing it! :)


Developer
Comment by Andreas M. Antonopoulos on May 29, 2012 at 6:01pm

Cameron, if the dronecell could transmit video, it would be at very very low rate and res. Most likely not possible, or not worth doing. 

The MAVLink protocol has sequence numbers. As far as I know if you send data out of sequence it will simply discard it on the receiving end. UDP should not be a problem and will definitely offer better latency results. 

Comment by Cameron Lattz on May 29, 2012 at 5:48pm

Andreas, we are not using the dronecell. In my opinion it is not capable of transmitting video of good resolution. We are using an onboard computer running Ubuntu. I understand that bandwidth is not an issue, because the size of the telemetry data could be easily written in bytes; by "faster" I was referring to the latency. Is the latency with UDP significantly less than with TCP?

If only receiving telemetry and video data, it is true that the sequence of the messages is not very important. But what if you are using the 3G connection to control the plane directly, as Ellis Akins and I are doing? If you sent joystick command A before joystick command B, is it not possible that joystick command B could be processed by the drone BEFORE command A?


Developer
Comment by Andreas M. Antonopoulos on May 28, 2012 at 10:47am

Cameron, very interested in your progress. Can you describe how you tethered the Android? 

On UDP/TCP, it is not an issue of speed, but an issue of latency. TCP introduces more latency.

Also, MAVLink is really a connectionless protocol (not based on sessions) and has its own packet sequencing. So UDP is a better "fit" and reduces the latency. 


Developer
Comment by Andreas M. Antonopoulos on May 28, 2012 at 10:44am

Asaak,

Very sorry for the delay. I have been working on another ArduPilot library (APM_Limits, aka geofence) that is going into the next release. The good news however is that I have learned all the things I need to fix the Cellular Modem library and make it easily configurable from MissionPlanner. 

As soon as I have news I will post here. I expect the next release to be much better!

Comment by Asaak on May 28, 2012 at 4:35am

Andreas,

any progress so far with the broken code??

Cheers!!

Comment by Cameron Lattz on May 22, 2012 at 2:29am

Ellis Akins and I are developing our own solution to telemetry and direct control over IP. We have successfully flown a quadrotor with a 3G TCP connection using a tethered Droid (for testing purposes...we will soon switch to 4G modem). Latency times are low enough to easily fly the quadrotor. In your experience, how much faster is UDP vs TCP, and with UDP, is input/output synchronization an issue?

Thanks,

Cameron

Comment by Asaak on May 22, 2012 at 1:12am

Hi Andreas!

How is it going with the code? Any updates??

Thanks for your work!


Developer
Comment by Andreas M. Antonopoulos on May 14, 2012 at 1:59pm

Asak, the code is currently broken. I have not had a chance to fix it yet. Please wait until I release the new test version, soon (a few days, a week at most)

Comment by Asaak on May 14, 2012 at 1:35pm

Dear all!

I compiled succesfully the code and upload it to the board. However, I had no success connecting to APM Plannner manager. Time out expires without connection. Any ideas?

Comment by Devin Johnson-Kinlaw on May 13, 2012 at 3:24pm

As for me, right now, I am working on a circuit to allow for different modes of direct control over the GSM/GPRS cellular network. Currently, I still advocate the uploading of new waypoints and directional constraints to the aircraft and'll probably never change my mind. However, I do fancy the idea of a more direct "transmitter-like" feel over cellular. I was stuck on the analogous approach of rapidly sending encoded frequencies up to 3.3KHz for PLL(Phase Locked Loop) decoding into a multi-channel servo driver circuit. Utilizing data may be the much better way. Coded properly, OSD video, telemetry, and live control over cellular can be achieved simultaneously.

Comment by Devin Johnson-Kinlaw on May 13, 2012 at 3:07pm

Okay, well then I'm right on track. As for programming, I would love to learn the process. For now, great going on the code, Andreas! Seems there are many people backing this up; this is an exceptional idea for long range UAVs and honestly believe more functionality must be accepted by the community. The enhancement and security of these technologies at the base level will make way for an exciting future in small-scale aviation. On the side, I envision the far future as a world where aerial model tech is widespread with abilities to ship small packages, food items, and such across the city. Just imagine the practical efficiency of using electric UAVs, solar assisted, etc. instead of getting in a bulky electric powered car to get groceries. I could go on and on. If anyone tests the legitimate use of "toy" airplanes, I have to laugh! These aircraft are definitely not toys.


Developer
Comment by Andreas M. Antonopoulos on May 13, 2012 at 1:00pm

@Devin, We have already been able to use the Drone Cell and other modems to send data directly from the telemetry port. As you guessed, the modem doesn't do much, it simply passes data back and forth. The new 3DR radios do a bit more than that, framing packets, buffering and also monitoring the heartbeat. 

For the time being, the simple transparent bridge approach works. So yes, it works, it has been done over IP over cellular GSM/GRPS and routed to a dynamic DNS. It works just like the Xbees. So yes, that part is done. 

Now it is a matter of testing and enhancing, especially in the area of configuration and integration into MP setup screens. I will be working on the code more this week!

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service