What This Shows
The full competition system boundary: physical crane structure, electronics integration, STM32 firmware, sensors, and actuators. Yellow dashed nodes are supported by the casefile; blue nodes are supported by inspected code.
Mechatronic Crane
Mechatronic Crane Competition System
Team: Yongye Hu Zhixiong Zhang Qiangjian He Huaying Wang Jiali Chen Jiahao Zhou Show all
Advised by: Professor Gang Zhao
Mechanical / PCB Integration Lead
Improved from national third prize to national second prize across two competition seasons.
- STM32
- Embedded C
- Mechatronics
- PCB design
- Motion control
- Sensors
Outcome Improved from national third prize to national second prize across two competition seasons.
Embedded systems, controls, mechanical packaging
Built and iterated a competition crane platform across two China University Student Crane Competition seasons. The project combined STM32-based embedded control, distance and attitude sensing, multi-axis motion, servo/pump object handling, mechanical packaging, and custom electronics integration. The public story is intentionally scoped to the competition crane; later mining-crane research and PLC work are separate from this case.
Impact Improved from national third prize to national second prize across two annual competition seasons.
Ownership Led mechanical packaging, PCB consolidation, assembly iteration, and hardware debugging while a partner owned control firmware.
Technical Focus Integrated sensing, motion control, object handling, and hardware reliability under nonlinear crane actuation constraints.
portfolio-gpt-pro-pack/reference/20260417-mechatronic-crane-reference.json and include the competition scope, award progression, hydraulic/fuzzy-PID rationale, 4-layer KiCad PCB consolidation, EMI debugging, and inverse kinematics. The visible 2023 firmware contains a conventional Position_PID implementation; fuzzy PID is supported by the casefile narrative rather than by the inspected 2023 code dump. Code-observed STM32 modules, UART callbacks, packet parsing, stepper/servo/pump routines, encoder reads, and conventional position PID.
Reference-backed Competition scope, award progression, PCB consolidation, hydraulic/fuzzy-PID rationale, EMI debugging, and inverse-kinematics narrative.
Inferred abstraction Lifecycle and task-flow diagrams condense call order into reviewer-readable phases rather than claiming a formal FSM.
System Architecture Diagram
flowchart LR Operator["Competition operator
starts run"] --> Crane["Mobile crane platform"] subgraph Physical["Physical System"] Mech["Mechanical frame
CAD + packaging"] Hydro["Hydraulic actuation
(casefile-backed)"] Gripper["Servo grippers
vacuum pump"] end subgraph Electronics["Electronics Integration"] PCB["Consolidated 4-layer PCB
(casefile-backed)"] STM32["STM32F103 controller
CubeMX / HAL"] Sensors["Distance, line, limit,
encoder + attitude sensors"] end subgraph Firmware["Firmware Modules"] Init["HAL init + UART callbacks"] Planning["Scan / slot map
task sequencing"] Motion["Stepper, motor,
servo + pump drivers"] Control["Position PID
encoder feedback"] end Crane --> Mech Mech --> Hydro Mech --> Gripper PCB --> STM32 Sensors --> STM32 STM32 --> Init Init --> Planning Planning --> Motion Control --> Motion Motion --> Gripper Motion --> Hydro classDef casefile fill:#fff7df,stroke:#b7791f,color:#2d2410,stroke-dasharray: 5 4; classDef code fill:#eaf4ff,stroke:#2b6cb0,color:#102a43; class Hydro,PCB casefile; class STM32,Sensors,Init,Planning,Motion,Control code;
Why It Matters Technically
The project was not just a controller or a mechanical build. It required co-design across packaging, electronics, sensing, actuation, and firmware behavior.
Skills Demonstrated
- Mechatronic system decomposition
- STM32 firmware integration
- Mechanical and PCB packaging tradeoffs
- Evidence-aware technical communication
Portfolio Copy
I helped turn a competition crane from a set of mechanical, electronics, and firmware subsystems into a competition-ready mechatronic platform. The architecture required coordinating physical packaging, custom electronics, STM32 control firmware, sensing, and actuator reliability rather than optimizing any one subsystem in isolation.
Key support: portfolio-gpt-pro-pack/reference/20260417-mechatronic-crane-reference.json, Crane_8_2023/fire_vet6_usart/Core/Src/main.c, GLOBAL/global.c, BSP_STEP, BSP_SERVO, BSP_DISTANCE, BSP_MOTOR, BSP_PID, BSP_ENCODER, packet/packet, plus earlier-season Crane_7_2022/User modules.
Main User / Data Flow Diagram
flowchart LR Start["Start Run
operator trigger"] Prepare["1. Prepare
init + home axes"] Perceive["2. Perceive
navigate + scan slots"] Pick["3. Pick Objects
boxes + cola/bottle"] Return["4. Return + Signal
reposition + beep"] Start --> Prepare --> Perceive --> Pick --> Return classDef actor fill:#fff7df,stroke:#b7791f,stroke-width:2px,color:#2d2410,font-size:16px; classDef firmware fill:#eaf4ff,stroke:#2b6cb0,stroke-width:2px,color:#102a43,font-size:16px; classDef sensed fill:#edf7ed,stroke:#2f855a,stroke-width:2px,color:#132a1d,font-size:16px; classDef output fill:#fdf2f8,stroke:#b83280,stroke-width:2px,color:#3b1026,font-size:16px; class Start actor; class Prepare firmware; class Perceive sensed; class Pick firmware; class Return output;
What This Shows
A reader-friendly view of one competition run, from operator start to completion feedback. It groups the 2023 firmware sequence into four task phases instead of showing every call.
Why It Matters Technically
The flow separates preparation, sensing, manipulation, and completion. That makes it clear how the crane turns sensor information into physical actions without turning the portfolio diagram into raw control-flow code.
Skills Demonstrated
- End-to-end embedded task orchestration
- Sensor-driven object handling
- Reader-focused technical abstraction
- Physical workflow design
Portfolio Copy
The competition routine starts by preparing the embedded controller and recovering a known reference frame, then uses slot scanning to guide object pickup and return. This diagram shows how low-level sensing and actuator routines were composed into a complete crane run rather than isolated device demos.
Key support: Core/Src/main.c calls Servo_Init(), backTo0(), chassis_PosCTRL(), scan(), Catch_BOX(), Catch_COLA(), and BeepApp(); GLOBAL/global.c owns homing/scanning helpers and object-slot bookkeeping; BSP_DISTANCE/bsp_distance.c supports ultrasonic recognition; BSP_SERVO/bsp_servo.c owns pickup routines.
Internal Processing Pipeline
flowchart LR
subgraph Inputs["Inputs"]
UART["UART callbacks
gyro + packet bytes"]
Sense["Ultrasonic, ADC,
limit + encoder reads"]
end
subgraph Processing["Processing"]
Packet["Frame parsing
angle / x / y packet"]
Recognize["Slot recognition
recognize()"]
Book["Occupancy map
book[6]"]
Planner["Task planner
scan + catch order"]
end
subgraph Outputs["Actuation"]
Stepper["Stepper commands
Yaw / X / Z / chassis"]
Servo["Servo + pump
grip and release"]
PID["Position_PID
encoder correction"]
end
UART --> Packet
Sense --> Recognize
Recognize --> Book
Packet --> Planner
Book --> Planner
Planner --> Stepper
Planner --> Servo
Sense --> PID
PID --> Stepper
What This Shows
The main firmware pipeline: interrupt-driven serial input, sensor recognition, occupancy mapping, task planning, and actuator commands. The PID block is limited to the conventional position controller present in the inspected code.
Why It Matters Technically
Real-world robotics code has to bridge asynchronous inputs, noisy sensing, persistent state, and timed motion commands. The pipeline shows where data becomes decisions and where decisions become physical movement.
Skills Demonstrated
- Interrupt-aware embedded architecture
- Sensor abstraction and calibration hooks
- Motion command generation over UART
- Closed-loop position control with encoder feedback
Portfolio Copy
The firmware connects UART packet handling, sensor recognition, object-slot bookkeeping, and actuator control into one processing pipeline. This structure made it possible to reason about object handling as a sequence of verified sensor decisions and bounded motion commands.
Key support: Core/Src/main.c UART callbacks and run sequence; packet/packet.c frame parsing; BSP_DISTANCE/bsp_distance.c ultrasonic recognition; GLOBAL/global.c slot scanning and book[6]; BSP_STEP/bsp_step.c motion commands; BSP_SERVO/bsp_servo.c gripping/pump control; BSP_PID/bsp_pid.c and BSP_ENCODER/bsp_encoder.c for position feedback.
Task Lifecycle Diagram
flowchart LR Init["1. Initialize
Boot STM32, configure HAL, enable UART"] Home["2. Home Axes
Reset servo, yaw, X/Z, and limit references"] Scan["3. Navigate + Scan
Move to task zone and map object slots"] Pick["4. Pick Objects
Run box and cola pickup routines"] Finish["5. Return + Signal
Reposition, return, and beep complete"] Init --> Home --> Scan --> Pick --> Finish classDef lifecycle fill:#f7fbff,stroke:#2b6cb0,stroke-width:2px,color:#102a43; class Init,Home,Scan,Pick,Finish lifecycle;
What This Shows
A five-stage lifecycle inferred from the sequential calls in main.c. It is a readable abstraction of the run order, not an explicit enum-based state machine in the firmware.
Why It Matters Technically
The lifecycle makes the competition routine easy to review: setup, homing, scan-and-map, pickup, and completion each have different hardware assumptions.
Skills Demonstrated
- Reverse engineering behavior from firmware structure
- Lifecycle modeling for embedded systems
- Separating explicit code facts from inferred design
Portfolio Copy
The firmware follows a sequential competition routine that can be understood as five hardware phases. This diagram keeps the lifecycle approachable for reviewers while clearly marking it as an inferred model, not a formal state-machine implementation.
Key support: Core/Src/main.c sequential run order and callbacks; GLOBAL/global.c homing/scanning; BSP_STEP/bsp_step.c motion phases; BSP_SERVO/bsp_servo.c object-handling phases.
Reliability Debugging Loop
flowchart LR Noise["Observed instability
EMI, noise, or drift"] Split["Isolate source
mechanical, electronics, or control"] Hardware["Hardware fix
PCB consolidation + wiring"] Control["Control check
Position_PID + motion routine"] Retest["Retest run
pickup, motion, return"] Boundary["Evidence boundary
casefile + inspected firmware"] Noise --> Split Split --> Hardware Split --> Control Hardware --> Retest Control --> Retest Retest --> Boundary Retest -. repeat if unstable .-> Noise classDef code fill:#eaf4ff,stroke:#2b6cb0,stroke-width:2px,color:#102a43; classDef casefile fill:#fff7df,stroke:#b7791f,stroke-width:2px,color:#2d2410,stroke-dasharray: 5 4; classDef inferred fill:#edf7ed,stroke:#2f855a,stroke-width:2px,color:#132a1d; class Noise,Hardware,Boundary casefile; class Control code; class Split,Retest inferred;
What This Shows
A reliability loop that separates casefile-backed EMI/noise debugging from code-observed position control. It is a debugging model for explaining the work, not a claim that every step appears as one formal firmware routine.
Why It Matters Technically
Competition hardware failures can look like controller problems until the physical, electrical, and firmware paths are isolated. This loop shows how the crane story should be read: hardware reliability first, control behavior verified second.
Skills Demonstrated
- Mechatronics failure isolation
- EMI and packaging-aware debugging
- Firmware evidence boundary management
Portfolio Copy
The crane improvement story should emphasize reliability debugging across electronics, packaging, and firmware behavior. The page keeps EMI and PCB consolidation as casefile-backed context while grounding inspected control details in the available STM32 code.
Key support: portfolio-gpt-pro-pack/reference/20260417-mechatronic-crane-reference.json for EMI and PCB consolidation context; BSP_PID/bsp_pid.c, BSP_ENCODER/bsp_encoder.c, BSP_STEP/bsp_step.c, and Core/Src/main.c for inspected firmware behavior.
Accuracy Notes
- The casefile describes a competition crane with hydraulic actuation, fuzzy PID selection, PCB consolidation, EMI debugging, and inverse kinematics; those claims are shown as casefile-backed rather than code-backed.
- The inspected 2023 firmware shows STM32F103 CubeMX/HAL code, UART receive-to-idle callbacks, serial packet framing, ultrasonic recognition, stepper motion commands, servo/pump gripping, encoder reads, and a conventional position PID loop.
- The inspected 2022 firmware supports the earlier-season integration story: line walking, distance sensing, ADC-based recognition, gripper routines, motor/timer control, and repeated pickup/place cycles.
- The existing portfolio metadata listed six team names, while the casefile describes a five-person competition team. This page preserves the existing names and avoids using a public team-size claim.