Project

# Title Team Members TA Documents Sponsor
17 John Deere Modular Vehicle Control Board
Samuel Huhta
Sumanendra Sanyal
Zachary Hoegberg
David Null design_document4.pdf
design_document5.pdf
final_paper1.pdf
proposal1.pdf
proposal2.docx
Sumanendra Sanyal, sanyal3
Sam Huhta, shuhta2
Zach Hoegberg, zh2

Modular PCB interface for John Deere equipment

Problem: John Deere currently manufactures an autonomous lawnmower that uses a buried wire to define the boundary of the yard. Furthermore , the hardware in the mower isn't applicable to other John Deere equipment. They would like to eliminate this wire by implementing a localization algorithm using a combination of vision, LIDAR, and other sensors, but the current Vehicle Control Unit does not have the necessary computing power to enable this.

Solution: We will replace the existing board with a modular microcontroller design capable of running Linux applications, consisting of a universal main board and machine-specific perception and vehicle boards. The modular design keeps the high-level automation code on the main board and swaps out perception boards and vehicle boards designed for a specific piece of equipment. The main board boots a LINUX system developed by John Deere for a particular piece of John Deere equipment. The vehicle board will drive motors or send command to the existing equipment as appropriate. The perception board will accept sensor input, for example from cameras and LIDAR sensors, and include a GPU for running a Deere-provided neural net or machine learning algorithm. The boards will communicate using ethernet/USB or some other method determined to deliver enough speed. All of the boards are custom-built microcontroller boards/PCBs that meet a specific hardware specification. The boards will have to demonstrate basic functionality by running test code (provided by John Deere software developers) and then they will run the actual code pertinent to the operation of the vehicle (also provided by John Deere). We intend to design these boards with the design of the the preexisting board at hand (non-modular design) and close coordination with John Deere PCB engineers and software developers.

Solution Components:
Power: SMPS Voltage Regulators so all of the boards receive a stable power supply from the on-board battery.
Main Board: This board is responsible for running the top-level Linux software. Unlike the other two boards, this one is the same for all vehicles. It contains a multi-core ARM processor, and it connects to the other two boards via ethernet/USB cables (or whatever method of communication we choose).
Vehicle Board: This board is responsible for dealing with the physical operation of the mower, and is connected to wheel motors, steering, Hall effect sensors, etc. The vehicle board is unique to the type of John Deere equipment and we will be demonstrating the vehicle board for the tango mower.
Perception Board: This board is responsible for taking in all the data from perception sensors, including cameras, LIDAR, and other potential sensors in the future. This board can be switched out in the future as other sensors are introduced.

Criteria for Success: The main board will boot the provided Linux kernel, and communicate with the vehicle board. The vehicle board will control the Tango drive motors as commanded by the main board. The perception board will deliver sensor data to the main board.

Additionally, Deere would like us to run a neural net on a GPU on the perception board, but they understand that adding that task may be out of the scope of a semester-long project. We will leave this as an optional task if time allows for the time being, and decide in the next few weeks if we can accomplish this task as well.

BusPlan

Aashish Kapur, Connor Lake, Scott Liu

BusPlan

Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

https://www.accuware.com/products/locate-wifi-devices/

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.