Timothy Barfoot, an autonomous space robotics researcher and associate professor at the University of Toronto, put together an excellent presentation on lessons learned from conducting field research in remote locations.
In this post, we’ve gathered the key takeaways from his presentation as well as insights from our Field Robotics Test Manager here at Clearpath, Martin Cote. Keep reading to find out what they wish they’d known about field research, and you won’t have to learn these lessons the hard way.
Tim says to ask yourself two questions:
Consider what the potential added value for being on-site is and what makes this field site unique compared to other potential ones. Could another location be better suited, or could you simply run the test with simulations? There’s no point going to all this effort without good reason, so before you do anything else, make sure you know why you’re conducting a field test in the first place!
Write down deadlines by which you will have accomplished major tasks, and hold yourself accountable. If extended travel is involved, consider the necessary date of your departure and work backwards from there.
Giving yourself buffer time before your final milestone and the end of your field testing will allow for margins of error and unexpected complications. It’s worth identifying the most time-consuming milestones ahead of time and accordingly scheduling around those.
Here’s a list of suggested milestones (Tim’s timeline allows for 1–3 months between each one):
Simply wrapping your equipment in protective coverings, boxing it up, and labeling everything can take at least a day or two. Plus, traveling takes a toll on any team’s energy. Make sure you schedule time to settle in and set up the field site before the official start of any research activities. If you are travelling separately from your shipment, be aware that shipping delays could skew your schedule.
Depending on where you’re going, it might make sense to get training in wilderness first aid and firearms. This can take a month or two to arrange for the whole team, so make sure you consider this when you’re writing your schedule.
During the planning stages, you’ll need to consider the logistics of how you’ll transport all your equipment.
Hard drives can fail suddenly, so it’s important to have redundant data storage. A RAID-protected server means your computer will automatically copy experiment data across multiple hard drives.
A dry run means running the experiment. Schedule time to work the kinks out of the interacting parts of your experiments before you plan to gather your experimental data. This is the best way to verify that you’ve actually got all the equipment you need, and you’ve got it set up properly.
We’ve included a few suggestions below (although this is by no means an exhaustive list).
Pelican cases are a great way to organize your gear and ensure that your equipment is protected during transport.
These highly visible outdoor notebooks are perfect for protecting your field notes from rain, stains, and wear-and-tear from daily pocket use.
Martin encountered such a need in the field: “When we did a few days of field research in a row, we brought a generator to make sure we had electricity for our laptops, and we made sure all our equipment was fully charged before we left.”
Make sure to keep your kitchen setup completely separate from the robots.
You want your test plan to be as detailed as possible. If something goes wrong, a detailed test plan lets you repeat the test with the exact same conditions, so you can isolate the effects of your desired test variable.
Without a test plan, your set of experiments will likely end up being conducted under many different unrecorded conditions, and it will be impossible to determine how your test variable is affecting the results.
For example, Martin and his team were once conducting an experiment to see how long a robot could drive without overheating. On their very first test run, the robot broke down under the strain of the heat much more quickly than they were expecting.
Fortunately, Martin says, “We had a detailed test plan, so we were able to test out different modifications to the cooling system under the same conditions every time. We also had all the tools set up so we could make the important measurements while conducting the tests, and we had all the temperature sensors already placed on the robot (otherwise it would have wasted time if we had to move sensors around or reconfigure the whole system). Eventually, we found the right combination of sand and heat sinks—something we couldn’t have done without preparing an effective test plan.”
Martin and his team recorded each of the following variables so they could keep the starting conditions consistent every time:
Quick tip: Print out and laminate the test plan, backup plan, and any other written procedures you might need.
It’s a good idea to have a laptop (or just a monitor) on the robot. Otherwise, here’s your situation: imagine a desktop operating without a screen. That works great most of the time, but if anything goes wrong, it’s hard to debug.
For instance, there could be a networking issue where you can no longer talk to the robot. Ordinarily you’d have to plug in your laptop with a cable and do an SSH to take control of the other computer, but that might not work if there’s a failure in the local area network (e.g. the ethernet cable). In the worst-case scenario, you’d have to get access to the computer running the robot, which could be difficult if it’s sealed below deck.
Why not save yourself all that hassle? In this case, having a screen and keyboard set up directly on the robot would let you solve the networking problem easily.
There’s a lot going on in field research experiments. A clear delineation of tasks allows each person to focus on a single goal. At the very least, you should assign one person to be the experiment director, and one to be a dedicated media person.
Martin says, “We had one autonomy engineer making sure the robot was doing the same path at the same speed over and over. We had one person responsible for safety—they held on to the emergency stop button and monitored the surrounding area to make sure no humans or animals got too close to the robot. Our ‘media person’ was there with a camera to film the whole experiment. And finally, we made sure one person on-site was always available to help out with a bit of everything.”
No matter how much you prepare, something’s bound to go wrong. Tim, provides the example of a time when he shipped a robot to the Arctic. It was clear that during shipping the robot’s crate was turned upside downside during transit, jarring a circuit board loose inside the robot making it inoperative. Luckily, they had all the necessary tools to straighten pins, solder broken connections on site and were back up and running within hours.