Overview

This research work focused on a lab hydraulic-crane prototype for remote intelligent mining equipment, separate from my earlier competition-crane work and separate from ROBOCON. The research problem was not just making a crane move remotely; it was making the control chain measurable enough for lab validation: command input, module response, sensor acquisition, hydraulic actuation, and posture feedback all had to line up.

My public version keeps the company, site, and commercial details out of scope. The useful engineering story is the prototype infrastructure: a control and calibration bench, a fused communication link, and a real-time position model that kept a digital twin synchronized with the physical rig.

Research boundary: this page describes the bench, link validation, and posture model I contributed to. It does not claim ownership of the full mining machine, dynamic-compensator algorithm, autonomous planner, or full inverse-kinematics planner.

My Role

I joined as one of the undergraduate researchers on a graduate-heavy team. My contribution sat across three connected areas: the remote intelligent control test bench, bench-level validation of the TCP/IP wireless to fiber-carrier RS485 communication path, and a forward-kinematics posture model running on STM32.

I am careful about the ownership boundary here. I worked on the measurement, integration, calibration, and digital-twin posture layer; I did not own the full mining equipment system, the dynamic-compensator algorithm, the autonomous trajectory planner, or the inverse-kinematics planner.

Key Results

• Built and operated a two-layer validation bench: PLC for machine logic and safety sequencing, STM32 for fast sensing and posture math.
• Instrumented posture and hydraulic response using angle sensing, inclinometers, pressure signals, and timestamped step/sweep tests.
• Defined a concrete calibration gate: repeated runs had to stay within offset tolerance, show stable lag, and stop drifting in overshoot/settling behavior.
• Integrated and tested the fused TCP/IP wireless to RS485 fiber-carrier path with framing, timeout, command/response, and latency/loss/jitter logging.
• Implemented a closed-form 3-DOF forward-kinematic chain on STM32 for turret yaw, boom pitch, and arm pitch, refreshing digital-twin pose at about 50-100 Hz.

System Architecture

Software / Firmware Architecture

Control / Simulation Methodology

The bench architecture deliberately split slow machine logic from fast posture sensing. PLC modules handled actuator enable, hydraulic valve commands, state sequencing, watchdog behavior, and emergency-stop logic, while the STM32 side handled sensor reads and the geometric pose calculation. That division made integration easier to reason about: machine-state faults and pose-estimation faults could be isolated instead of blending into one opaque control problem.

The digital-twin model answered a specific question: given the current joint and posture sensor readings, where is the boom tip in space? I used a closed-form geometric chain rather than a heavy planner, mapping sensed joint angles into an estimated pose fast enough that the twin behaved like control feedback instead of a slow visualization.

Validation & Debugging

On the communication path, my work was practical systems integration. I wired and validated the RS485/fiber path, checked that wireless commands could pass through the full chain reliably, and added timestamped logging so the team could reason about round-trip delay, packet loss, and jitter.

The calibration gate was concrete: repeated runs had to stay within offset tolerance, response lag had to stabilize, and overshoot/settling behavior had to stop drifting.

What I Would Improve

I would preserve more raw validation logs and calibration traces for future publication. The architecture was strong because it made the bench measurable, but the public-facing page can only cite what remains safely documented. I would also document ownership boundaries at the start of team research, not only retrospectively.