Microchip’s PIC32 MCU has proven effective for myriad applications, so why not a dog collar? Learn how these Cornell graduates built a GPS-enabled pet collar prototype. The article discusses the hardware peripherals used in the project, the setup and the software. It also describes the motivation behind the project, and possibilities to expand the project in the future.
People have a multitude of ways of staying in touch with each other. These days we can call, text, email, instant message, Snapchat or video call anyone with cell service or Wi-Fi—and write letters to anyone who doesn’t. It’s important for human beings to be in contact with one another, but what about their pets? There aren’t as many ways of checking in on your furry friends while you’re away from them. As a final project for our class on “Digital Design Using Microcontrollers” at Cornell University, we built a wearable smart device that can be attached to a pet collar. Equipped with Wi-Fi and GPS capabilities, the collar lets you follow Lassie’s adventures from wherever you are.
The system runs on Microchip Technology’s PIC32 microcontroller (MCU) and is outfitted with a small army of peripherals from Adafruit. These include the Ultimate GPS breakout board, the Huzzah ESP8266 breakout board and the 9-DOF (degrees of freedom) Absolute Orientation IMU Fusion breakout board. The device displays real-time data to a webpage that the user can access over the Internet. A portable 5-V USB battery pack is used to power the system. The block diagram in Figure 1 presents a high-level overview of the full system.
The PIC32 is mounted onto a small development board designed by former Cornell student, Sean Carroll . The board takes in 5-V and regulates it down to 3.3-V, which powers the MCU. The GPIO pins and the power outputs on PIC32 are brought out onto headers, so that the board can easily be mounted onto a breadboard along with the peripherals. Figure 2 shows the schematic for the entire system, and Figure 3 is a photo of our prototype.
The combined surface area of all components—excluding the battery pack—can easily fit onto an average dog collar. The weight of any collar being worn by a mammal is ideally within 5% of its total body weight , a requirement that this design meets for most dogs. The USB battery pack can be replaced with a smaller battery pack or a rechargeable battery, if desired. For testing purposes, the battery pack was a convenient, if bulky, solution due to its high charge capacity. The rendering in Figure 4 shows potential placement of the MCU and peripherals in a flexible collar. Important design aspects to be considered here include appropriately enclosing all electronics to prevent contact with water, fur or skin.
Let’s take a look at each major element of the design one by one.
Software: Our software on the PIC32 consists of three threads and a main function. Each thread is dedicated to one peripheral and handles the communication with the corresponding module. The threads were implemented using the Adam Dunkels’ popular lightweight protothreads library for C , modified for PIC32 by Dr. Bruce Land . The GPS thread spawns a child thread to read the serial input buffer for the PIC’s UART2 channel, and parses the NMEA sentence received if it is in valid GPS message format. The IMU (inertial measurement unit) thread uses a I2C helper function to read accelerometer values in the X, Y and Z directions. The values are used to determine whether the dog is active, to set flags and to update variables. Finally, the Wi-Fi thread encodes the data collected from the other modules into a string and communicates it to the Espressif Systems ESP8266 by spawning a child thread. The child thread puts the data into the serial output buffer on the PIC32’s UART1 channel. The main function takes care of configuring and enabling I2C1 on the PIC32, configuring the IMU, and initializing and scheduling the threads.
GPS: We used the Adafruit Ultimate GPS breakout board to collect geolocation data, such as latitude and longitude coordinates and the time in EST. The board has a MediaTek Labs MTK3339 chipset, a high-quality and low-power GPS module able to track up to 22 satellites and perform location updates at a rate of up to 10 Hz. The module sends a steady stream of NMEA data to the PIC32 via UART2 at the default baud rate of 9,600 bps. The sentence is transmitted in $GPGGA format, which refers to the Global Position System Fix Data format . Once the PIC32 confirms that the NMEA sentence is in the correct format, it parses it and extracts the desired values from it. We powered the module using 3.3 V from the PIC32 development board.
The UART functions used for communication were adapted from Junyin Chen’s and Haonan Liu’s project, “GPS Navigator for Runners” , which used the same GPS module. The GPS thread spawns a child thread, which reads and parses the UART2 serial input buffer, using functions defined in the GPS UART header file. The child thread yields to other threads until data are available in the serial input buffer. Once a byte is available, it reads it and stores it in a character buffer. If the character received is a newline character, ‘\n’, it signals the end of the string, and the buffer is zero-terminated. Otherwise, the buffer index is incremented, and the character received is added to the buffer. After the entire NMEA sentence has been collected in the buffer, it is verified and parsed to obtain the required information using a simple state machine.
IMU: To give the users a general idea of whether their pet was active, A 9-DOF BNO055 IMU was used to detect the movement of the collar. The IMU interfaces with the PIC32 using the I2C protocol. It outputs accelerometer, gyroscope and magnetometer readings that can be used to generate measurements for yaw, pitch and roll for the device on which the IMU is mounted. We had initially planned to use the IMU to facilitate step counting on the device; however, we soon realized that a device mounted on a pet’s collar would not be able to provide data accurate enough for such an application. Moreover, counting a pet’s steps would also have been heavily dependent on the type of animal, and would have required a more in-depth analysis of what motions would count as a “step” for that particular pet.
With all that in mind, we chose instead to use the accelerometer on the IMU to indicate whether the device was in motion. A rough velocity calculation was implemented using the accelerometer readings. A nonzero velocity value indicated that the device was in motion, whereas the velocity was consistently zero when the device was at rest.
To receive data from the IMU over I2C, we used macros and helper functions from a previous ECE 4760 project by Ashley Xue, Jessica Chen and Adam Chung . The header file
i2cIMU.h defines the device address and the different data registers on the IMU, and the helper function
i2c1ConsecutiveRead() is used to read from two consecutive registers on the IMU. It does so by taking in a start register address and the number of registers to be read (which is always 2). It returns a “short” (a short is a 16-bit data type value), with the value from the first register stored in the LSB and the value from the second register stored in the MSB (most significant bit).
Wi-Fi: The Adafruit ESP8266 Huzzah breakout board was used to provide Wi-Fi connectivity to the device. Like the GPS module, the ESP8266 communicates with the PIC32 through UART. The PIC32 runs threads that communicate the parsed data from the GPS module and IMU to the ESP8266 by writing to the UART1 buffer. This is done by spawning a child thread that uses a helper function to write data to UART1 serial output buffer. This thread was implemented with the help of sample code from the Cornell ECE 4760 course website  and the helper function was adapted to use the UART1 channel instead of UART2. The ESP8266 was programmed using the Arduino IDE. This is discussed in further detail in the next section.
To display all the data generated in a centralized location, we first had to collect it from the different peripheral modules and transmit it to the Wi-Fi module. To make our design useful, we needed to use the ESP8266’s abilities to display the data to a webpage. Programming the ESP8266 can be tricky, but as with most Adafruit components, there are plenty of handy guides out there to help the process along.
Adafruit’s Huzzah breakout board ships with NodeMcu’s Lua interpreter pre-programmed onto it, but it can also be programmed using the Arduino IDE. We decided to use the latter, because we were familiar with the Arduino interface and there were many more libraries available online that supported it. Neither of us had any prior experience with web development or setting up clients and servers using an MCU, but after some tinkering around we were able to connect the ESP8266 to a Wi-Fi network, start a server and write HTML code to a local webpage. The program uses the Adafruit ESP8266 libraries
ESP8266Wi-Fi  and
ESP8266WebServer  and Arduino’s
WiFiClient  to handle the backend processes of setting up a web server and client.
After more experimentation with the ESP8266 module, we enabled it to scan through multiple Wi-Fi networks in a predetermined order, and connect to the first one available. We were also able to use the module to write dummy data to a remote webpage. We hope to extend the functionality of our project to include writing to a remote webpage in the future.
TESTING AND RESULTS
We verified device functionality by checking that the data returned from each individual peripheral were valid within a certain margin of error. For instance, when our GPS module indicated that we were in the middle of Europe, we knew there was something wrong. But when it briefly seemed to think we were on the other side of the street, we were willing to let it pass. Similarly, the activity level output by the IMU was verified by ensuring that the output was zero when the device was at rest and nonzero otherwise—where the nonzero value represented a crude velocity calculation.
The accuracy of the GPS was further verified using the Google Map embedded into our webpage. The latitude and longitude data received from the GPS was plotted onto the map and displayed. By comparing this map with our current location using the Google Maps website, we were able to confirm whether we were actually at the location indicated by the GPS. We tested our device around different parts of the Cornell campus. Figure 5 is a screenshot of the Google Map our device produced when we tested it indoors in the Undergraduate Lounge in Phillips Hall.
A map of the various rooms in Phillips isn’t included in this article, so you’ll have to take our word that the lounge actually is by the point indicated. The marker on the map actually lines up very closely with the windows of the lounge, which is where the device was set up. To calculate the percentage error, we recorded the latitude and longitude coordinates output by the module for several other locations, and compared them with the corresponding coordinates obtained using Google Maps. Our results are summarized in Table 1. The relatively large error for the Gates Hall latitude entry was most likely due to the measurement being taken indoors.
The device activity was detected using accelerometer readings as described in previous sections. This provided a dependable indicator of motion to convey whether the device was in motion or stationary. We tested this functionality by walking and running with the system, and monitoring the raw data displayed on our webpage. An example of our readings can be seen in Figure 6. The small but nonzero velocity value indicates that the device was in motion.
Our design packs a punch because of its small, but powerful and reliable hardware. With a pocket-sized USB battery pack, it can easily be attached to the collars of pets weighing 10 pounds or more. However, the usability of the current iteration of our design is fairly limited. This is because our design requires the Wi-Fi modules on the collar and the pet owner to be connected to the same Wi-Fi network. This means that the pet owner can only monitor his/her pet if they are within the Wi-Fi range—for instance, if the pet is in a different room in the house. The system’s functionality could be improved greatly by enabling the Wi-Fi module to write to a remote domain, which the user could access from any Wi-Fi network. This would allow pet owners to view their pets’ data from any location and on any Wi-Fi network. We had some success experimenting with these features, but discovered that full integration would require time beyond our project deadline.
Another addition required to make the system practical and marketable would be the ability to configure it from a user standpoint. For instance, a potential user would want to pre-program the device to scan for a few Wi-Fi networks. They might also want to configure what data they want to receive about their pets, and the frequency at which they would like to receive the data. Further, a user login could be implemented to allow only verified users to access the data.
Other highly requested functionalities include heart rate monitoring and step counting. While working on our project, we were able to interface successfully with the hardware required for both these features. However, to make the collected data truly useful, we would have to examine aspects of our design much more closely. We would have to identify how the movement patterns detected by an IMU located on a collar of an animal can be translated into steps, and determine ideal placement of a pulse measurement device to pick up heart rate accurately through fur.
Last but not least, our final design set us back less than $85, including a $20 battery pack. The closest competitor currently on the market—that we were able to identify—is the Link AKC Smart Dog Collar  which costs from $80 to $100 depending on the size, and requires a monthly payment for a service plan. This leads us to believe that our design, once extended to include the changes mentioned above, could be a marketable product if manufactured.
For detailed article references and additional resources go to:
References  through  as marked in the article can be found there.
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • MARCH 2019 #344 – Get a PDF of the issue