Frequently, navigating on your bicycle involves reaching in to your pocket numerous times to check the map on your iPhone, or worse, holding it in your hand while you ride. For those that navigate frequently - or long distances - on bicycles, we'd like to develop a device that can clearly lead the way while keeping your eyes on the road and your iPhone safely stowed away. waterproof, shockproof navigation for your bike.
What it does
Our device - attached to your handlebars - shows your route and directions to your destination, by communicating with the cloud through your mobile device (iPhone, etc.). After entered your destination on an iPhone app our device receives map data from the cloud through the iPhone's cellular connection, and data is transferred between our device and the iPhone by a wifi connection. On-board GPS will provide location lat/long/alt data, that is then processed through Google Maps' static API and receives back a map image that will be modified to display on our LCD screen. The LCD screen will have two display modes - one for day and one for night - which will be controlled automatically by phototransistor. And a superbright 1W headlight will light the way when you need it to.
How we built it
We began by outlining our system components' interactions with the SAMW25 by using Atmel Start, and identified the communications channels that we would use for our needs. GPS (USART), IMU (I2C), LCD screen (SPI)
After designing the sensor, actuator, communication and power systems around the SAMW25 wifi platform, GPS, and IMU, we outlined how these components would be arranged on our device... -- power switch in the back of the housing alongside a micro-USB for charging our 3500mAH LiPo battery -- phototransistor on top next to our LCD screen and status LED indicator -- and headlight in front.
5V and 3.3V components were isolated in different sectors of the custom PCB, which is elliptical in shape to fit into our ellipsoid housing. and PCB layout was driven by larger components with the most connections, and keeping trace length to a minimum where possible.
Our bootloader is triggered to read downloaded firmware and directly write to the NVM of the processor, one page at a time, until complete. After which, the bootloader jumps to the application firmware until another trigger to download.
Challenges we ran into
We faced some challenges during the creation of this project, documented below by category:
--PCB Design: The PCB design process had some challenges on the manufacturer's end in that some of the Gerber files seemed to register incorrectly in their system. Secondly, in placement of the parts, the manufacturer was unable to get all the footprints placed correctly once the final product was received. The multiple back and forth attempts at solving these challenges led to a significant delay on our timelines.
--PCB Bringup: Once the PCB had arrived, bringing up the board revealed some components were placed incorrectly or missing. Specifically, the external clock was unable to communicate with SAMD21 MCU. Eventually, we resorted to using a more fully functioning SAMW25 Explained Pro board and have the sensors on a breadboard.
--Sensor Integration: Given that our sensors would be connected on a breadboard, we had to use two SAMW25s given our need for 2 SPI interfaces (SD Card and LCD), a UART TX and RX, and a GPIO. After solving our connection issue, integrating the libraries for the sensors were also a significant challenge given their implementation in C++ and our project being implemented in bare metal C.
Accomplishments that we're proud of
Our PCB design
Firmware Update from SD card to NVM
What we learned
A system video can be found here