I’m Roman, part of The Boring Illini, a student engineering team at the University of Illinois Urbana-Champaign. We’re building a fully electric tunnel boring machine for The Boring Company’s 2026 Not-a-Boring Competition in Bastrop, Texas.
We’re putting together the analysis and validation workflow for our control systems, and we’re exploring automation tools that student engineers can use responsibly. Most UiPath material I’ve found targets business processes, so I wanted to ask here directly:
For a hardware team running physical tests and collecting sensor data, which parts of the testing and data pipeline are worth automating first, and which are better kept manual? And what’s the best way for a student team like ours to connect with the Academic Alliance program?
We’re also actively looking for support to get this machine built, both financial donations to fund fabrication and testing, and hardware contributions like components, materials, or equipment access. If anyone here knows the right people at UiPath for student team partnerships, I’d be grateful for a pointer.
Automate these first (high repetition, low judgment)
Sensor data ingestion. Automatically pull logs from your DAQ / PLC / microcontrollers after every run and save them with a consistent naming scheme (date, test ID, config, firmware version). This alone saves hours.
Data cleaning and formatting. Unit conversions, timestamp alignment across sensors, and removing obviously corrupt rows. Write it once and run it every time.
Standard plots and summary reports. Torque, thrust, motor current, temperatures, vibration, and advance rate. Have a script generate the same set of charts and a one-page summary after each test so runs are directly comparable.
Threshold and limit checks. Flag any run where a value crossed a limit (overcurrent, overtemp, pressure spikes) so nothing slips past a tired reviewer.
Test log and record keeping. Auto-fill the test log (who, when, setup, results file links) into a shared sheet or database.
Regression checks on control code. Every time the control firmware changes, replay recorded or simulated inputs and confirm the outputs still behave as expected. Keep these manual, at least for now
Anything touching safety or the physical machine. E-stops, interlocks, power-up and power-down, and go/no-go decisions should stay in human hands. Don’t put a business-automation bot in the loop for live machine control.
Test setup and pre-run checklists. A human should physically verify wiring, sensor mounting, and calibration. Automation can present the checklist, but a person signs it off.
Interpreting unexpected results. Scripts can flag anomalies, but an engineer should decide what they mean and what to change.
Calibration of sensors. Do it manually and document it carefully. Automate only the record keeping.
Early-stage tests. While your procedures are still changing every week, keep things manual. Automate a step once it has stabilized and you’ve done it the same way 5+ times.