Connecting your robot to the internet can be tricky and there are a lot of mistakes you can make when implementing a connectivity solution. This list comes from interacting with hundreds of robotics companies that have signed up for the Freedom Robotics platform and have needed a stable wireless connection.
We have seen everything from misconfigured robots that drive off uncontrolled when a connection drops to companies that deployed robots to new operating areas and couldn’t get a decent signal when their coverage map showed complete coverage. Learn from the mistakes of those that have gone before you to avoid some of the biggest pitfalls you might encounter along the way.
1) Selecting The Wrong Data Plan
Minimizing the cost of operation is of critical importance when deploying a fleet of robots and selecting the wrong data plan can shift your numbers in the wrong direction very quickly. It is easy to underestimate your data usage, blow past your data limit and rack up a monster bill. As most carriers will charge somewhere in the neighborhood of $10 per gigabyte for exceeding your plan limits, you can find yourself in the red very quickly. I have done this myself when doing some stability testing on a new robot charging system. I left my robot uploading more data than I needed for a few weeks on an LTE plan and got a huge bill for the data overage. (Tip: If this does happen to you, don’t be afraid to try to negotiate the bill down a bit as most providers do have some flexibility with data overages.)
The key to managing your bill is finding a data plan that fits your needs. If your robot’s use case is uploading massive amounts of inventory data or raw industrial inspection data then you will need a substantial data plan. However, if your robot simply sends home an “I’m alive and healthy” ping every few minutes then you can get away with a much more limited plan. The best way to understand your specific data needs is to do some testing.
Through Freedom Robotics software you can measure this easily by selecting the STREAM page and you will instantaneously see all the details of your bandwidth consumption.
Configure your robot the way you are going to be using it in the field and measure how much bandwidth you are actually using. Once you know the rate of data usage you can easily calculate your monthly usage by multiplying your rate by the amount of time you expect to deploy your robot per month.
2) Selecting The Wrong Carrier
Each carrier uses different bands in the electromagnetic spectrum, each band will have different coverage over a specific region and each cellular modem will only be compatible with certain bands. So you might look at the coverage map of a specific carrier and see that your operating area is completely covered, however there may only be 1 band from that carrier in your area which can result in degraded performance. Even worse, your modem might not even support the bands that are available in your operating area. For example Verizon Wireless uses bands 2, 4, 5, 13, 46, 48 and 66. Your modem may say that it supports Verizon Wireless because it uses bands 5 and 13 and your operating area shows 100% Verizon coverage. If your operating area is covered by bands 2 and 4, you could potentially have no connectivity at all because your modem does not support the bands available in your operating area.
The best way to avoid this mistake is with testing. Before committing to a connectivity solution take a real robot out for some real world testing and see how it performs. Try to get some modem test units from a few manufacturers and cell cards from multiple carriers and run benchmark tests in your operational environment and see how they stack up.
Here is a good resource that will explain a bit more about the specific bands that each major carrier uses in their network.
3) Not Testing For Connectivity Loss
When operating a robot remotely small gaps in connectivity are inevitable and it is imperative to understand how your robot will handle those situations. One particularly nasty failure mode we have seen more than once is when a robot is executing a drive command through teleoperation and experiences a loss in connection, the robot will latch to the last drive command and continue driving on it’s own resulting in an unsafe condition.
The team at IHMC Robotics Lab are always testing the boundaries with their Boston Dynamics Atlas. Be like IHMC and test!
Test, test, test! Always test how your robot will handle a connectivity drop before sending it out of the lab. We highly recommend testing your robot during a connection loss to ensure there will be no unexpected behaviors. One simple way to test this is to put your robot on blocks so that the wheels can move but are not in contact with ground. Send in a constant drive command and unplug the router to disable the connection. You need to ensure your robot is configured so that it stops moving when the connection drops. You should also run this test with any other commands you send to your robot that could result in unsafe conditions if handled improperly.
4) Not Matching Your Solution To Your Needs
You want to find a connectivity solution that matches your connectivity needs. If you are relying on a cellular connection to tele-op your robot around urban environments then using a single carrier USB LTE stick will set you up for failure as you can expect poor signal reception and occasional connection dropouts. Additionally, if your application only requires an occasional connection to send home a heartbeat, then you might not need a high end dual cell card router; this will add unnecessary cost and complexity. A further consideration is the headache associated with sending out a robot technician. If you are operating your entire fleet within walking distance of your operations center then occasional trips to the robots is not a huge problem. However, if sending out a robot tech means putting someone on a plane then you are better off investing in a great connectivity solution early on.
Understand exactly what you will and will not be relying on a connection for and make sure your connectivity solution meets or exceeds the bandwidth speed and reliability requirements of your use case.
5) Using a Single Sim Card When Dual Is Needed
When selecting a connectivity solution adding a dual sim router may seem excessive, however if connectivity is critical to your robot’s use case having that extra sim card will add a safety net that increases your robot’s up time and decreases the workload on your robot support team dramatically. Another big advantage of a second sim is that you have a bit more flexibility in plan selection. You can select your primary sim to be one with lower data rates and slightly less coverage and have your secondary sim card use a network with better coverage that is more expensive. That way the majority of your data usage is on a less expensive network and you get better coverage than would not be possible with any single carrier. One important thing to be aware of when selecting a dual sim router is the switchover time - the amount of time it takes to switch from carrier A to Carrier B. On most dual sim routers this will take a few minutes, which is not ideal if it happens when you robot is crossing the street.
If connectivity is critical for your use case then go with a dual sim router. One standout dual sim router for robotics applications is the PEPLink Max Transit Duo line shown below. This router has an almost instantaneous switching speed between different cell cards without the need to purchase extra equipment. Some of the features of this router that standout are:
- Dual Sim
- No delay when switching between sim cards
- Cloud configurable
- Very fast connection speeds. This router also supports Speedfusion where it can take data from both sim cards simultaneously. Speedfusion does not work right out of the box and does require some additional configuration.
PEPLink Max Transit Duo. Here's a link to PEPLink’s website for more info.
6) Not Taking Advantage Of Wifi When It Is Available
Commonly robots are deployed to areas that have wifi, but with frequent dead spots preventing full reliance on wifi, for example hospitals, warehouses, hotels, retail environments and college campuses. Many higher end routers have the ability to configure a connection hierarchy so that you can use wifi when available and if it is not then default back to cell card A , then cell card B if needed. Using a router with a cloud enabled device management like Cradlepoint’s Netcloud or PEPLink’s InControl 2 will enable you to configure network settings and the connectivity hierarchy of your robot fleet remotely. Taking advantage of available wifi can help significantly reduce data consumption and also increase connection coverage and connection speeds.
If there is going to be Wifi at the location you are deploying to … use it! One useful hack we have seen many robotics companies use is to ship new robots on location with a router installed with a functioning cell card. Then when the customer unboxes and powers on the robot, the operators can go in remotely and set up a connection to the wifi and use that as the primary connection to get the robot operational.
7) Not Having A Stable Power Connection
This may sound basic, but barrel jacks have a tendency to come loose. Many routers have some flexibility in how you power them and often plugging in a barrel jack connector or a usb is the simplest solution. Constant vibration and challenging operating environments can cause barrel jacks to come loose.
Always use terminal blocks to connect your power source to ensure you get a stable power connection. If a consumer grade product ends up making its way into your robot and you don’t have terminal blocks to connect to, a little hot glue can go a long way to help make a barrel jack or usb connector more reliable.
8) External Antenna Placement
One company we have worked with is doing sidewalk delivery and they mounted their antennae under their storage compartment. This worked great for them until they got a delivery order for a lot of milk and juice and the liquids blocked the signal to the antenna. A good external antennae can make a world of difference when it comes to keeping your robot connected out in the real world. Whether you are dealing with urban canyons or trying to maintain a signal on a remote farm, an external antennae will help you make the most of whatever signal is available.
Best practices for Antenna placement are to always mount your antenna as high as possible and make sure there will be no obstructions. Also making sure your router supports standard SMA connectors will ensure compatibility with the highest performing antennae. Taoglas is a great resource for finding an external antenna for your use case. We have had many customers who have had good experiences using their products.
9) Additional Tip: Getting Network Firewall Permissions
We got a lot of positive feedback from the community when we first published this blog. One of our good friends Nicolas Beucher, a veteran in the robotics space and lead on one of the most popular telepresence robots, shared a tip and we wanted to make sure we passed it along.
When accessing commercial networks, IT firewalls can pose a serious barrier to a good connection. Nicolas shared that on some of the bigger robotics deployments he has done, the biggest challenge in connectivity is enabling wifi networks to correctly allow robot data through firewalls. Commonly IT departments won’t have the necessary ports open for the sake of security and often critical services can get blocked by a firewall. Nicolas did a lot of coordinating directly with IT departments and found that most of the time they are more than happy to help, you just have to speak their language. The principal concern with most IT departments is security which means they default to keeping all doors shut and only open them when they know precisely why they are needed and have clear direction on exactly what to open. Nicolas has had great success working with a myriad of different IT departments by developing a standard document to give to them that clearly communicates his exact needs. In his experience IT managers don’t read lots of text so he kept the format simple with the bottom line up front, bullet points and a clear layout.
Be like Nicolas! Get all your ducks in a row before talking to IT and make their job as easy as possible for them, use minimal text and highlight requirements in a bulleted format. Here is a list of all the information that Nicolas would communicate to IT departments in his documentation:
- Router / Firewall configuration requirements and port forwarding
- Local Area Network Internet Protocol addressing requirements
- Inbound Traffic (Network Address Translation and Port Forwarding)
- List TCP ports and usage
- Outbound Traffic
- List client, TCP ports and usage
- Needed signal strength
- Signal to Noise ratio requirements
- Bandwidth needed
- Latency requirements
We assembled this list because we see the same mistakes being made repeatedly and want to help robotics companies learn from the mistakes of others. Selecting a wireless router can be daunting but if you can manage to avoid these common pitfalls then you are already ahead of the curve! As always, we love hearing back from the robotics community. You can email us at firstname.lastname@example.org or sign up for a free trial account to test our platform and ping us on chat to get going!