Belt marking machine with laser integration

ROS 2 control software, a Gazebo digital twin and a touchscreen interface for a machine that feeds, laser-marks and cuts belts.

Gazebo model of the belt marking machine with a belt reel, a laser head over the conveyor, a knife station and a signal tower
When
Since 2019
Origin
Built at Lazer Market, rebuilt in ROS 2
Built with
  • ROS 2 Humble
  • Gazebo
  • Raspberry Pi
  • Arduino Mega
  • PyQt5
  • SQLite
  • YOLO
  • MQTT
  • OPC UA
View the code on GitHub Watch the original machine on YouTube

As R&D engineer at Lazer Market I developed a tape-feeding machine that works together with a CO₂ laser. The machine feeds a belt or label tape, triggers the laser to mark it, and cuts it into pieces with a pneumatic knife. This repository is that machine’s control software, rebuilt on ROS 2 with a simulation of the whole process.

It runs on a Raspberry Pi with a touchscreen. An Arduino Mega handles the real-time I/O. The controller never knows whether it drives the real machine or the simulation, because both offer the same ROS service and topic.

Touchscreen production screen showing machine state EXECUTE, marks 2 of 12, and START, HOLD, RESUME and STOP buttons
Production screen.
Touchscreen job setup screen with fields for belt width, number of marks, mark pitch and laser time
Job setup.

What it does

  • Four job modes: continuous marking, cut every piece, cut every N labels, cut at the end of a batch.
  • Up to four laser machines along the belt, each with its own offset and delay.
  • A PackML-based state machine with 23 coded alarms, each with a defined reaction and a remedy text.
  • Recovery after a laser timeout, knife fault or belt run-out without losing counts.
  • Recipes, jobs, production log, alarms and OEE stored in SQLite, with CSV export.
  • An 800 × 480 operator interface with PIN roles, in English and Turkish.
Diagram of the machine layout along the belt and the planner’s stop positions for laser marks and knife cuts
The planner turns a job into a sorted list of stops along the belt.

Tested in simulation

Twelve scenarios cover normal production, six faults and an eight-hour shift. The simulated shift produced 10,498 labels at 93.6 % OEE with three injected faults. The cycle-time model and the simulation agree within 1.4 to 2.9 %.

An optional camera checks every label with either an OpenCV inspector or a YOLO11n detector trained on synthetic images. All AI parts sit outside the safety path: they report, and the controller decides. Safety functions are hard-wired through a safety relay.

Browse by topic