Snow Groomer Automation System

Project Background

At VTSU Randolph we have had a ski hill since around 1939. The original rope tow was installed in 1960 and replaced in 2011. It operates under purely natural snow conditions and is open to all VTSU Randolph community.

The current initiative targets adding automated snow grooming capability to the ski hill with the first project by the 2024 mechanical class capstone having developed a proof of concept chassis from snowmobile tracks. This proof of concept is shown in the second image on the right.

Project & Problem Definition

This project is Amelia Vlahogiannis, Luke Williams, and I's senior project.

The objective of this project is to design and implement an automated control system for handling drive, navigation and safety as well as supporting future expansion.

Requirements:

Self & Situational Awareness (Replacing the human’s senses)
Operation Modes:
- Manual (Remote Control)
- Automatic Drive Control (Replacing the human)
  - Grooming path navigation
  - Emergency decision making
Safety
- Mechanisms for Machine & Technician Safety
- Guards & Indicators for Bystander Protection
- Emergency Break on Electrical Loss
Design Considerations
- Must Be Weatherproof
- Must Be Expandable

This project started in late November (with a pause during holiday break) and was completed on 5/13/26. This page is last updated as of 5/18/26 although is not complete yet. More content is planned, particularly more sub-pages going into more detail with testing and design process of different parts of the project.

Randolph Community Expo Project Poster

On April 18th, the VTSU Randolph campus held its Homecoming & Community Expo day with associates and senior projects displayed for visitors, alumni, and administrators. Below is the poster we created for the project display.

Project Subsystems & Division of Responsibilities

Below are two images, the first being our draft block diagram and the second being our division of responsibilities. These are not finalized diagrams and may receive updates throughout the project.

Draft block diagram of the solution, is currently revision 1 and could continue see updates throughout the project. The first main change made was condensing the operation and sensor controllers into a single controller.

Division of responsibilities diagram used for determining which requirements fall on which member of the team.

Microcontroller

Luke and I developed a list of requirements for a microcontroller as well as features we would like to learn. Those requirements and extra features are below:

(2x) CAN Controllers, one was to be used to communicate with the navigation controller and one with the motor drivers
(1x, more wanted) ADCs, originally I had planned on a large number of analog sensors, requiring at least one full ADC although more would be useful to avoid pinout conflicts
(dual-core wanted) This was to allow my sensor code to not hold Luke's drive program back due to the slow speed of the sensors and their processing relative to drive decision making.

From these requirements I selected the STM32H755ZI-Q, Luke reviewed and approved of this selection. Throughout the project we found other features to be useful:

(8x) Hardware UARTs This was a mixture of standard UARTs and USARTs, which ended up all being used with 2 for the motor drivers (instead of CAN), 1 for the navigation controller (instead of CAN), and the ultrasonic sensors used for demo purposes using the remaining 5 U(S)ARTs
(6x) Hardware SPIs So far only 1 SPI was used, with it being for the MAX31855 thermocouple amplifier. In the future if more thermocouples are added for other locations on the snow groomer, the other 5 SPIs could find themselves used.

From an analysis, we predict these other features will come in useful in the future:

(6x) Hardware SPIs, as mentioned with only 1 used so far, there could be 5 more sensors added whether they be thermocouples using the MAX31855 chip or other sensors
(4x) Hardware I2Cs, based upon research on low resolution thermal cameras, it appears to be common for I2C pixel streams to be used, which would make these useful in the future.

Due to the selected controller having multiple cores, I learned how to set up and run inter-process communication using shared memory and hardware semaphores on the STM32 controller. Once I learned this I wrote a file which would be shared between the two core projects and would handle all inter-process communication using separate read and write functions to abstract both cores from the memory directly and having all shared data being stored in structs, one for system data and one for obstacle data.

Sensor Subsystem

Safety and emergency decisions are made using data collected by the sensor subsystem, which is broken into two parts: system monitoring, obstacle detection.

System Monitoring

The system monitoring part identifies and estimates the state of the system for use in decision making. The three datasets collected are from the motor drivers, interior temperature thermocouple, and from a hall effect current sensor. The current data is used to estimate the battery charge using an integral of the current (charge and discharge) measured over time.

The diagram above is a simple diagram representing how components within the system are connected for system monitoring.

On 2/18 & 2/19 the thermal and current sensing proof of concepts were demonstrated, a video of the demo is below. The demo is from revision 2 which used a lowside current shunt resistor instead of a hall effect current sensor switched to for revision 3 as well as only integrated the discharging, and not the charging as also added into the plan during revision 3.

Obstacle Detection

The obstacle detection system concept uses ultrasonic sensors to identify obstacles and infrared (IR) motion sensors to identify whether the obstacles are humans (or other animals). The identification of a human/animal compared to a static obstacle is important, as animals may move to avoid the snow groomer in the same direction the snow groomer moves to avoid the animal. The easiest way to visualize this is when two people walk towards each other in a hallway and both move back and forth trying to avoid each other in the same directions until hopefully someone doesn't allowing the paths to not collide.

After testing it was concluded the IR sensors were sensitive to vibration caused by the vehicle, the two solutions to resolve this that are being considered are validating their data with the obstacle sensors and/or use IR sensors which are designed for mobile use, which will require further research. After the ultrasonic sensor testing was completed, it was concluded that ultrasonic sensors cannot reliably detect humans, likely because clothing absorbs sound waves. Because of this issue, if the obstacle sensors were to validate IR data, a different technology would have to be used.

Above is a diagram showing how the 5 zone system would conceptually look, with all 5 zones being covered by both ultrasonic and IR for full obstacle and human precense detection. The software interface developed for inter-process communication between the sensor core and the drive core of the microcontroller takes into account both ultrasonic IR data, despite at the conclusion of this phase of the project only ultrasonic being used, with IR being postponed until another team updates the automation system.

Below is a video of the obstacle detection demo, for the reasons shown above the detection technology will be changing either in part or entirely. To ensure the operational control system can remain the same, the sensor data processing will be required to process into a consistent "data packet" to be used by the operational control system acting as an abstraction layer.

Due to the issues discussed, the product pruced this year did not include IR sensors although it did include the software interface for IR sensors to have their data uploaded to for decision processing.

Final Presentation, Demo, and Deliverables

The final presentation was on 5/4/26 with demoes throughout the following week and a deliverables date of 5/13/26.

The expected deliverables were [deliverable status: FULL DEMO/SUBSYSTEM DEMO/DELIVERED/NOT DELIVERED]:

Operation System (Drive & Decision Control) [FULL DEMO, DELIVERED]:
- Implemented hardware & software
- Provided Code
GPS navigation [PARTIAL]:
- Including path generation [NOT DELIVERED]
- Including path following [FULL DEMO, DELIVERED]
- Implemented hardware & software [DELIVERED]
- Provided code [DELIVERED]
System Monitoring: current & temperature sensing [SUBSYSTEM DEMO, DELIVERED]:
- Implemented hardware & software
- Provided code
Obstacle Detection [SUBSYSTEM DEMO, DELIVERED]:
- Finalized abstraction interface
- Ultrasonic obstacle detection array
- Implemented hardware & software
- Provided code, concepts, and research
Safety [PARTIAL]:
- Drive indicator lights [DELIVERED]
- Safety beacon [DELIVERED]
- Mechanical guards [NOT DELIVERED]
- Electrical loss emergency break [NOT DELIVERED]

Page updated

Google Sites

Report abuse