Turnkey Open Hardware and Software for Conservation, Science, Exploration, and Education
Portable Network Graphics (PNG) - 4.74 MB - 08/14/2017 at 04:46
Pretty much every sensor deployment we've done has been to remote areas with little or no connectivity. It can take days to reach some locations, either off roading through unforgiving terrain, boating in over crocodile infested waters, or hiking over rocks, ice, and snow. Sometimes we've been able to get status over satellite, but the bandwidth and power budget usually mean that the truly useful status and diagnostic information is left sitting idly on disk until the station can be visited again physically. It's stressful setting up a station and then leaving the poor thing behind, hoping that nothing was forgotten and that enough testing was done.
Over the last few months our efforts have largely revolved around some work we're doing with WCS and FIU in the Amazon jungle. Most of the stations there have been of the breed we're used to, left on their own to fend for themselves. Lately we got word that a future site would have WiFi, which for us is a pretty unique opportunity for a few reasons. First, we'll be able to get higher fidelity diagnostic information and data from these stations. In addition, given the right preparation, we'll be able to service the firmware on these stations remotely.
Being able to remotely upgrade firmware is a feature I've been wanting for a while. Given the state of the FieldKit project we've never really had a reason to expend the effort for the feature, though. This recent news was a great opportunity to justify that initial groundwork work.
Now that the feature is implemented and being tested, I wanted to write up a post going over what the feature took. So, get ready, this is a software heavy post.
At a high level, the basic premise is that the station would periodically check with our servers to see if there is new firmware available. If there is, the firmware is downloaded and then stored in the Serial Flash chip. Once completed and verified, the MCU sets a flag in memory indicating the self-flash should be done and then restarts itself. At startup our custom bootloader checks for this flag, and if set will reprogram the MCU's flash memory from the binary in the external flash chip.
When remotely upgrading module firmware the process is very similar. The Core module (the one with the WiFi) will check to see if any of the attached module's firmware is outdated, downloading the binaries if necessary. Then that binary is transferred to the module over I2C, verified, and the module restarts itself in a similar fashion.
This is one area where us deciding to include serial flash memory as a standard "Module" feature was a good idea. This process would have been more awkward, otherwise.
It's important to us that all of the work we do fit comfortably within the OSS/OSH ecosystem that's evolved from Arduino and similar platforms. This work represents the largest deviation from that work, so far. Though it's possible to use our code/hardware with standard bootloaders and simply forgo that functionality in your own projects.
Most "maker" focused development boards in the Arduino ecosystem come pre-installed with a bootloader of some kind. This is a small program, usually less than 8k or so, then runs before application code and provides friendlier ways of programming the MCU. For example:
Now would be a good time to mention that all of our boards use the ATSAMD21G18 chip, the same one from the Arduino Zero boards and the Feather M0 line. So most of what's here applies to them and another Cortex M* chips....Read more »
Botswana's Okavango Delta is one of the most incredible places on this planet. Named a UNESCO World Heritage site for it's biological diversity, the Delta is a pristine habitat for all the charismatic megafauna that subsaharan Africa is known for: elephants, hippos, lions, giraffes, and more. It is one of the most incredible places that I have ever been and the need to monitor and protect it has never been more necessary. It was in this magical place where FieldKit was born, with support by the National Geographic Society.
FieldKit was inspired by a collaboration between National Geographic Explorers Shah Selbe, Steve Boyes, and Jer Thorp. Steve was conducting biodiversity surveys of the delta from canoes year-after-year in the same old ways that scientists have done for decades (if not longer). While working in the field in Botswana, Angola and Namibia, the team realized that there were few good open source hardware and software tools that met the specific needs of field research. Not only in sensor technology but also ways to organize and visualize the data. Responding to this need, Shah and Jer began to prototype software and hardware solutions and field-tested these approaches from 2014 to 2017.
We wanted to share the science and the story behind the expedition real-time, so anyone could join and provide insight or support. By turning Into The Okavango (ITO) into a live-data expedition, we have been able to bring thousands of people along with us on expeditions in the Okavango Delta (including an astronaut that was following along from the International Space Station). We collected, stored, and shared 40 million open data points and continuously measured ‘the heartbeat’ of this crucial ecosystem through large-scale open source sensor systems.
This experience we had with ITO was transformative, and it made us realize that we should bring these same capabilities to anyone anywhere in the world by giving them a publicly available, fully featured ITO of their own. The lessons learned and understanding that came from years of continuous field use allowed us to architect FieldKit in way that can be scaled and expanded across various users regardless of how much they know about engineering and computer science. Scientists have already been embracing social media and blogs to share their expeditions with the world visually, but there wasn't a good tool out there for them to do that same sharing scientifically. @Jacob Lewallen has been helping with the hardware and software development on a volunteer basis since the beginning, and stepped in as FieldKit's Principal Engineer at Conservify in 2017.
We already have additional working partnerships with scientists to use FieldKit in their efforts, which include:
In our previous post, Shah outlined our most recent project with the Tropical Rivers Lab at Florida International University and gave a high level overview of the work we've started with them. I wanted to take some time to talk about how valuable the real world work is in providing feedback on FieldKit ecosystem.
It's inevitable in field work that you'll find yourself working with conditions or constraints that you didn't anticipate, even more so when you're the one who has designed the hardware you're using. Ever since my first field experience I've tried my best to keep meticulous notes on the issues I encounter, their solutions, and ways they could be avoided and mitigated in the future. These notes are incredibly valuable compared to in-lab testing of hardware and physical enclosures by virtue of many important facts:
I'm going to quickly go over some of the changes we've made recently, directly due to the efforts of preparing these stations for the field.
Board sizes evolved haphazardly until recently. I've begun rounding them to easy to remember dimensions.
Oh connectors. Connectors have been one of the largest frustrations I've had. We've recently begun incorporating Molex connectors on our boards to link modules to the Core board. The connector is a 5 position one, carrying I2C, power, and Vbus (unused for now) This went so well that one change I wanted to make was use them for even more things, not just the Core/Module connection. We decided to increase our use of these connectors in these ways:
So far used we've been using side-entry USB and JST connectors exclusively. Somewhere around the third board I realized that vertical entry USB would be way more useful in situations where the enclosure is an off the shelf box. Side entry, especially on the ends of boards, requires internal space to be be able to use the connector. Otherwise, you've got to lift the board from inside the enclosure to insert a USB cable when flashing or charging, etc.. The same goes for the JST connectors we used for batteries, though to a lesser extent because they tend to be more maneuverable than USB cables. Right now we're testing hybrid USB and JST footprints that allow either part to be soldered on. We'll be reporting back on how successful this is, especially with regard to the frankenprint we're using for the USB.
FieldKit is designed to work with many different scientific applications, across various deployment scenarios and geographic locations. That requirement came from the type of work we do at Conservify, which can vary from partner to partner. One goal for this Residency at the Supplyframe DesignLab is to get us into a product line focus instead of the constant one-off projects that we have been doing time-after-time. We want to build something useful for the scientific community, that allows for anyone with any scientific level of knowledge or goal can go out and start learning about the world. We wanted to standardize the tools so we could start to focus on the projects in the field and getting the critical data that was necessary for the scientists and conservationists.
One of our implementation partners for FieldKit is a project called Ciencia Ciudadana para la Amazonia (Citizen Science for the Amazon) that is run by the Wildlife Conservation Society through support by the Moore Foundation. This past week we had a milestone for the project: we were sending out the first prototypes of the environmental sensors that will be used in the Ecuadorian Amazon. This milestone kept us very busy this last week, so much of our 0x03 residency was focused on getting the hardware and software ready for deployment. These included:
The photos above were of a few of the systems in their final integration, before we left them in Miami for the trip to Ecuador. Later project logs will cover the construction of these and some of the changes that we will undertake from the lessons learned over the last few weeks.
The plan was to take this hardware out to Quito (Ecuador) for the 2018 AQUATROP conference, where the team behind the Amazonia project had a large scientific representation. There was a showcase where the FieldKit sensors were deployed and many additional implementations were discussed with future partners.
Our partners for this first deployment (seen in the photo above) is the Tropical Rivers Lab at Florida International University. Every Conservify project partners with scientists (either at a university, government, NGO, or even citizen scientists) to handle the specific scientific questions around the technology we develop. This can be things like where to deploy, what to measure, and the specific requirements around the data we need. Getting the scientific question correct is fundamental to the technology development pathway.
Over the course of this project, we will outline some of the other work we are doing with other FieldKit partners and the expeditions that we go on during the development and deployment.
Posting this slightly late project log from last week, as we prepare for some upcoming tasks for FieldKit. We have quite a bit happening in both in the handheld device and in some of our upcoming deployments in the Amazon Rainforest with the Wildlife Conservation Society. More on both those in the coming weeks.
We sent out for the panels for the handheld version to a New Zealand-based PCB supplier that Dan had worked with in the past. This is both for the main MCU and sensor board. They are separated (as Jacob mentioned in an earlier post) so we can mount the sensor board close to the enclosure for more accurate readings. Those sensors measure temperature, humidity, ambient sound, and ambient light.
Jacob has been pulling together the component orders for the pick-and-place machine, which has been an interesting exercise. We have only hand-built PCBs before so our quantities were much lower. Once you start looking into reels and trays of components, the numbers can really add up. Fortunately the common providers like Mouser and Digikey have smaller sub-reels that would be perfect for the runs we plan to do here at the DesignLab. We are still finding the right balance on quantities since we are not in full production yet.
For all the other sensor boards (water quality, weather, etc), we are still ordering the trusty purple boards from out friends at OSH Park. They have been fantastic supporters of FieldKit since the Open Hardware Summit last year.
Product Design Ideation
I have been working a lot on what the look and feel of FieldKit should be as we get into the enclosure design. Jacob and I both come from engineering backgrounds, so some of these industrial/product design stuff is new to us and we were really excited about those opportunities that would come out of the DesignLab residency. I already had a fantastic chat with Majenta and Giovanni about best practices around designing a product like that. The plan is to start on the handheld version (what we frequently call the "Naturalist") and design some solid 3D prints of potential enclosure designs that we can touch and feel. Using those, I will ask for feedback and we can discuss which one meets the feel that we are seeking for FieldKit in general. As these are to be used out in the field, we want them to have an outdoorsy vibe (much like the stuff that Best Made does so well):
We also want the product to follow the branding that we have built for Conservify and started to develop alongside FieldKit partners Office for Creative Research (which, tragically, is no longer around) and the National Geographic Society. For those who haven't been following along for long, FieldKit came out of work we had done with OCR since 2014 as part of the Okavango Wilderness Project. That project came out of a collaboration between a few National Geographic Explorers to bring live data from the field during a biodiversity survey expedition in Botswana's Okavango Delta (more here and here). The branding and color schemes (as currently stands) looks like this:
Finally, there are some functional characteristics that we want for this handheld version. These are:
Happy Monday everybody, hope you’re ready for another update! Things were fairly quiet this week as Shah was in Washington DC for the National Geographic Society Explorer festival. My focus was on the preparation for scaling up the manufacture of our FieldKit Naturalist boards.
We have two goals on this front. The first is the assembly of a panel of boards using the pick and place machine at the DesignLab and the second is having the capability of sending away for assembled boards from a 3rd party. In order to be ready to send away for a panel of PCBs, a quick design review was necessary.
This was fairly straight forward as we have some working prototypes that I hand assembled in our lab and so we have pretty high confidence in our current board design. We did make some changes, though:
In ramping up for the pick and place we need to begin ordering pick and place friendly parts - reels and trays. We try and keep all of our BOM information in our schematic files. This means that going into this process each part already had a supplier name and supplier part number, typically from Mouser. Because many assemblers have their own preferred supplier for basic parts like passives, Dan suggested we keep manufacturer details in the schematic as well.
One of the things I love most about Kicad is how scriptable things are. It was easy to export a CSV of the parts and then fill in MFN (Manufacturer Name) and MFP (Manufacturer Part) there and then update the fields in Kicad from that. We also have scripts that go over all of our boards and their parts and look for parts with out-of-sync manufacturer and supplier information. We want the authority to be the schematic, but with several boards keeping the details consistent can be time consuming. Scripts help with that.
Soon, I hope to write a project log about our “grouped spread and place” script. This is...Read more »
Last week, the Conservify team started their tenure at the SupplyFrame DesignLab Residency! This opportunity is something we've been looking forward to for several weeks and we're very excited. This first post is going to outline the current state of FieldKit and give a brief rundown of the goals we have for our time at the DesignLab. A kind of "state of the project" to set the stage for future updates.
State of the Hardware
FieldKit’s evolution began where many present day electronics projects do, as a series of glued together prototype boards from Adafruit and the internet at large. After a couple years bouncing between various MCUs in the Arduino space for various one off projects we eventually settled on the Adafruit Feather line, specifically those containing the ATSAMD21G chip (their M0 boards). We liked the variety they offered, the compatibility with Arduino tools and libraries, and the trade off the chip made between power and capabilities. It was nice having all the peripherals as well as the memory when compared to other Arduino boards. They became a natural choice as we began prototyping the various FieldKit modules. This post assumes you’re slightly familiar with our project so please read the summary if you haven’t.
This may be a good time to point out that Arduino compatibility is important to us as a feature for two reasons. First, we are hoping to provide a platform people are comfortable hacking on and modifying for themselves and Arduino provides that framework. The second is related, and that is that it's important to us that we have something approachable for STEM related applications.
So, going into the residency we have early versions of the following modules designed and being tested:
Our core module is our most complicated board and was the first one we began designing last year. This board is pretty densely packed for our standards and includes GPS, SD, Serial Flash, WiFi (WINC1500), LoRa, LiPo Fuel gauge and charging, and some other smaller systems.
Water quality based on the Atlas Scientific line of sensors. This board has room for five Atlas modules of any kind. We’ve been designing the board to be populated with ORP, DO, pH, Temp, and EC. In the next few weeks we'll also be adding a pressure sensor to this module for depth readings.
This module is designed to work with the relatively cheap rain/wind weather meters available at a few online retailers. It also has a separate PCB that holds a few environmental sensors like temperature, pressure, humidity and ambient light.
A very basic module for attaching to a sonar sensor for water depth readings. This board also has a LoRa module and charging abilities because of certain slim municipal deployments we're anticipating.
This board is effectively a Core board and a Weather smashed together with two other sensors thrown in, specifically an SPH0645 MEMS microphone and a BNO055 IMU. This was originally developed to be a separate module but was merged into a single board to save space and simplify the project. It will also be one of our early focal points at the DL residency as we experiment with enclosure fabrication.
Naturalist is also special because when we designed the integrated single-PCB version we did so anticipating using that as a basis for a new version of our Core board. Core had gone through enough revisions that we felt things could benefit from a redesign.
State of the Software
Our firmware is mostly C++ with some C sprinkled throughout. We keep separate repositories for our module specific...Read more »