GSoC 2026 · Week 12 · Coding period

Week 12: One workcell, many palletizing patterns

Earlier in the project, the palletizing setup proved an important first point: the UR10 could pick a box from the conveyor and stack it on a pallet.

This week, the question changed from can the robot stack boxes? to what pallet layout should it build?

The result is a more interesting exercise direction. The same UR10, suction cup, conveyor, and SKU box pipeline can now produce different palletizing outcomes by changing the placement strategy rather than rebuilding the workcell.

From a fixed stack to a palletizing decision

The first stack was intentionally simple. That was useful for proving the complete manipulation loop, but it did not leave much for a student to decide.

The updated setup works with named box families, each carrying known dimensions. The planner receives the current box information and the usable pallet area, then decides where that box belongs.

In simple terms, the loop is now:

incoming SKU box
      ↓
box dimensions + usable pallet area
      ↓
choose a palletizing pattern and target
      ↓
robot picks and places the box

The simulator, conveyor coordination, suction attachment, and robot motion stay behind the exercise helpers. The interesting part for the learner is the placement decision.

One setup, several pallet patterns

The main achievement this week was turning the same physical workcell into a small pattern gallery.

The robot does not need a new arm, a new conveyor, or a new simulator scene for each result. The difference comes from the planner: how it chooses rows, layers, directions, and orientations for the incoming SKU boxes.

Row / shelf packing

The baseline strategy fills the available pallet area row by row. It is the most approachable starting point for SKU palletizing: a longer box consumes more row length, while a smaller one can use the remaining space.

This gives students a clear first algorithm without asking them to solve a full industrial optimization problem.

Brick-inspired alternating layers

The next strategy changes the direction used to fill each layer. Instead of repeating exactly the same seams above one another, the planner starts the next layer from the opposite side.

This is a useful introduction to the idea that pallet patterns are not only about fitting boxes inside a boundary. They also influence how seams, support, and visual structure are distributed through the stack.

Rotated block layout

The rotated-block pattern adds orientation as a planning decision. Some boxes are placed with a rotated footprint, changing the block structure without changing the feeder or robot setup.

This is an important step for the exercise because it connects a simple student decision—choose an orientation—to a visibly different pallet result.

Full MEDIUM-SKU pinwheel

The most visual pattern explored this week is a pinwheel-style layout. Rectangular MEDIUM SKU boxes are arranged around a central opening, alternating horizontal and vertical placement directions to create a full spiral/perimeter layer.

The initial small ring was useful for checking the geometry. The fuller MEDIUM layout makes the intended pattern much clearer: a pallet layer can be designed as a deliberate structure, not merely a collection of boxes placed wherever space is available.

Making physical placement match the plan

Pattern generation only matters if the physical placement matches the intended layout.

One of the important improvements this week was making pickup depend on the box’s actual stopped position on the conveyor. Earlier, the robot assumed an ideal pickup point. In practice, simulation physics can leave a box slightly away from that assumed location, which is enough to create placement drift later in the stack.

The feeder now observes the active box position before announcing it as ready. The pickup helper then uses that observed pose to bring the suction contact to the top center of the box.

This made the pattern experiments much more meaningful: the planner can reason about box centers, and the robot has a better chance of carrying and placing those centers consistently.

Keeping the workcell reusable

The native launch workflow was also cleaned up so the workcell can be restarted more reliably between pattern experiments.

The launcher now brings up the scene, UR10, MoveIt, RViz, conveyor bridge, and SKU feeder together, while cleaning stale processes from earlier native runs. This matters during pattern work: a layout failure should be traceable to the pattern or reach constraints, not to an old bridge or duplicate action server still running in the background.

I also started reducing unnecessary background work in the simulation, especially while tracking the active conveyor box. That will matter more as patterns use longer sequences and larger stacks.

What I learned from the pattern experiments

A pallet pattern is not just a list of coordinates.

The box footprint, approach direction, robot reach, pickup alignment, and available orientation all influence which layouts are practical. Some patterns are visually simple but require more careful geometry than expected. Others, such as row/shelf packing, are easy to describe but become more interesting when box sizes vary.

That is exactly why this is a useful RoboticsAcademy exercise direction. Students can begin with a simple placement rule, then improve it by considering orientation, alternating layers, support, and pattern structure.

What’s next

The current work will continue beyond this pattern gallery.

The next focus areas are:

• validating and refining the larger pinwheel layout at all of its outer positions,
• making longer pattern runs more predictable under simulation load,
• improving recovery when a robot movement cannot be completed,
• and extending the exercise from palletizing toward depalletizing: planning how a robot can safely remove boxes from an existing stack.

The workcell is now becoming a palletizing exercise rather than one fixed stacking demo. The next step is to keep turning these layouts into reliable, reusable learning activities.

Until next week 👋

GSoC 2026 · Week 11 · Coding period

Week 11: A slower week and more SKU planning

This week was not a normal coding week. I was ill, so I could not put in the same amount of implementation time as the previous weeks.

Instead of forcing a half-finished feature and pretending it was a milestone, I mostly used the limited time I had to review the SKU-based palletizing direction from last week and think through what should come next.

Revisiting the scope

The main question was how ambitious the first SKU version should be.

It is tempting to jump straight to a rich palletizing problem: mixed dimensions, rotations, interlocked layers, dynamic collision objects, placed-box tracking, and maybe even batch planning over the full sequence. But that would make the first student version too heavy.

The better first step is still the smaller one:

• boxes arrive online, one at a time,
• each box has a known SKU and dimensions,
• the pallet exposes a safe usable area,
• all first-version boxes keep the same height and width,
• the student writes a simple row/shelf placement algorithm,
• and the backend hides the simulator and planning-scene details.

That keeps the exercise educational rather than overwhelming. A student can understand why LONG takes more row space than SMALL, and can improve the placement strategy later.

Keeping the HAL boundary clean

I also spent time thinking about the API boundary.

The easy but wrong path would be to expose backend mechanics directly: let the student add collision boxes to MoveIt, detach named Gazebo links, or manipulate planning-scene primitives. That would technically work for a demo, but it would teach the wrong layer of abstraction.

The exercise should expose palletizing concepts, not simulator plumbing.

So the direction remains a simple chain:

/box_ready tells us which box arrived
        ↓
GetBoxInfo(name) gives SKU + dimensions
        ↓
GetPalletInfo() gives usable pallet area
        ↓
student computes the placement target
        ↓
HAL handles motion, suction, and feeder coordination

For example, the student should think in terms of data like this:

{
  "name": "box_412_0",
  "sku": "LONG",
  "size": [0.60, 0.30, 0.20],
  "mass": 2.5
}

and pallet limits like this:

{
  "frame": "base_link",
  "usable_size": [1.20, 0.90],
  "top_z": -0.60,
  "max_layers": 2
}

Then their job is to answer: “where should this box go?”

If placed boxes need to become collision objects later, that should happen behind a semantic call such as registering a completed placement, not through a raw add_collision_box(...) API in the student template.

What still needs work

The main unresolved part is runtime reliability with SKU boxes.

The old fixed-box demo was predictable because every placement was known ahead of time. SKU palletizing changes that. The robot still needs clean approach and retreat motions, but the stack is no longer just a fixed grid of identical cartons. The planning side needs a better story for the carried box and the growing stack.

From last week, the attached-collision-object experiment was not stable enough to keep, so the next attempt has to be more careful. I would rather keep the current HAL simple and stable than add a collision feature that causes more planning failures.

The next practical steps are:

1. Rebuild and retest the Infrastructure feeder split in the launch flow.
2. Confirm the /box_info and /pallet_info metadata arrive correctly in Academy.
3. Run the row/shelf reference solution end to end.
4. Decide whether the first SKU demo should use conservative motion and a simplified usable area, or wait for a stronger internal collision manager.

What’s next

Next week I want to get back to implementation and testing: stabilize the SKU-based runtime, make the row/shelf placement path reliable enough for a demo, and keep the student-facing code focused on the actual palletizing algorithm.

Until next week 👋

GSoC 2026 · Week 10 · Coding period

Week 10: Starting SKU-based palletizing

After the upstream sync, the next question was: what should the exercise actually teach beyond a fixed pick-and-place loop?

The first version stacked eight identical boxes in a neat 2×2×2 grid. That was useful because it proved the conveyor, UR10, suction, MoveIt, and HAL all worked together. But palletizing becomes interesting when the placement is not just “next hardcoded coordinate”. Real palletizing is about deciding where a box should go based on its size, the available space, the current stack, and the pattern you want to build.

So this week I started shifting the exercise toward SKU-based palletizing.

From fixed boxes to SKU families

Instead of jumping straight to arbitrary random dimensions, I started with a constrained setup: a few named box families, or SKUs.

The first planned set is:

The important simplification is that all boxes have the same height and width for now. Only the length changes.

That keeps the first student algorithm approachable. Instead of solving a full 3D packing problem, the student can think in rows: choose a layer, choose a row, and find the first free slot where the current box fits. Rotation, interlocked layers, occupancy grids, and batch optimization can come later. The first version should teach the shape of the problem without turning into an industrial optimizer.

The physical pallet is still 1.60 × 1.30 × 0.10 m, but the first SKU task exposes a smaller 1.20 × 0.90 m usable area inside it. That gives safety margin around the edges and keeps the targets inside a comfortable reach envelope for the UR10.

The task now lives in YAML

The old demo had a lot of geometry baked into the solution: box dimensions, target spacing, layer height, and the assumption that every object was the same.

For SKU-based palletizing, that has to move out of the student solution. The task should describe what is arriving, and the student’s code should decide where to place it.

So I added a task configuration file:

CustomRobots/palletizing/config/palletizing_task.yaml

It is the single place that describes the first SKU task:

pallet:
  physical_size: [1.60, 1.30, 0.10]
  usable_size: [1.20, 0.90]
  max_layers: 2

boxes:
  skus:
    SMALL:
      size: [0.30, 0.30, 0.20]
      mass: 1.5
    MEDIUM:
      size: [0.40, 0.30, 0.20]
      mass: 2.0
    LONG:
      size: [0.60, 0.30, 0.20]
      mass: 2.5

  sequence:
    - LONG
    - MEDIUM
    - LONG
    - SMALL
    - LONG
    - MEDIUM
    - LONG
    - SMALL

That sequence is important: this is online palletizing. The student does not receive the whole batch and optimize it ahead of time. One box arrives, the student places it, and then the next one arrives.

Changing the exercise is now much easier. If I want to try a different SKU mix or pallet usable area, I can edit the YAML instead of rewriting the feeder logic.

What the feeder publishes

The feeder now exposes simple JSON messages for the current box and the pallet.

When a box reaches the pickup point, the feeder keeps publishing its name on /box_ready, same as before. Along with that, it publishes box metadata on /box_info.

Example /box_info message:

{
  "name": "box_412_0",
  "sku": "LONG",
  "size": [0.60, 0.30, 0.20],
  "mass": 2.5
}

The name is the actual Gazebo model name for this run. The sku, size, and mass are the semantic task data the student cares about.

The pallet data is published separately on /pallet_info:

{
  "frame": "base_link",
  "size": [1.60, 1.30, 0.10],
  "usable_size": [1.20, 0.90],
  "center": [0.0, -0.88, -0.90],
  "top_z": -0.60,
  "max_layers": 2
}

The key detail here is frame: "base_link". The student solution and MoveIt commands work in the robot base frame, so the pallet metadata is translated into that same frame. The student should not have to know the Gazebo world offset of the robot base.

In plain English, the messages mean:

That is the data contract for the first SKU version.

How the ROS flow works

The runtime loop is still intentionally simple:

1. box_spawner reads palletizing_task.yaml.
2. It creates the next box from the SKU sequence.
3. It writes a temporary SDF model with the correct size, mass, inertia, and color.
4. It spawns that model in Gazebo using ros_gz_sim create.
5. It starts the conveyor by publishing to /conveyor/speed.
6. After the estimated travel time, it stops the conveyor at the pickup point.
7. It publishes /box_ready and /box_info repeatedly.
8. The Academy HAL receives the ready signal and metadata.
9. The student solution computes a target pose and picks the box.
10. The solution calls HAL.BoxDone(name).
11. The feeder checks that the name matches the expected box, then starts the next one.

The name check matters. If a stale or wrong /box_done message arrives, the feeder ignores it instead of advancing the sequence incorrectly.

Here is the same flow as a compact diagram:

YAML task
   ↓
box_spawner ROS node
   ↓ spawn SDF box
Gazebo + conveyor
   ↓ box reaches pickup
/box_ready + /box_info + /pallet_info
   ↓
Academy HAL
   ↓
student solution chooses target
   ↓
/box_done
   ↓
next box

This keeps the simulator side and the student side separate. The feeder owns the world mechanics; the student owns the placement decision.

Files and responsibilities

The feeder had become too much of a single large script, so I split the SKU work into smaller files with clearer jobs.

This split makes the code easier to explain too. If a student asks “where do box dimensions come from?”, the answer is the YAML and task_loader.py. If they ask “who moves the belt?”, the answer is box_spawner.py. If they ask “where is the algorithm?”, the answer is the reference solution.py.

Extending the HAL

On the RoboticsAcademy side, the HAL now listens for the metadata topics and exposes them through two calls:

box = HAL.GetBoxInfo(name)
pallet = HAL.GetPalletInfo()

So the student solution can stay high-level:

name = HAL.WaitForBox()
box = HAL.GetBoxInfo(name)
target = planner.next_pose(box)

pick()
HAL.BoxDone(name)
place(box, target)

That is a much better exercise boundary than asking the student to subscribe to ROS topics directly.

The reference planner is intentionally small. It keeps a used_length value for each (layer, row) pair. For each incoming box, it tries layer 0 row 0, then the next row, then the next layer, and places the box in the first row where its length fits.

Conceptually:

for layer in layers:
    for row in rows:
        if used_length[row] + box.length <= usable_length:
            place box here

It is not an advanced packing algorithm, but that is the point. It gives students a clean baseline they can understand and improve.

The hard part: collision and reliability

The SKU metadata path is now in place, but the full runtime is not fully solved yet.

Different box sizes make the stack more dynamic. The planner needs to avoid the conveyor and pallet as before, but eventually it also needs to understand the growing stack and possibly the carried box. I tried an experiment with MoveIt attached collision objects for the carried box, but it made planning less reliable, so I reverted it instead of leaving a half-working mechanism in the HAL.

That is an important design line: students should not have to call low-level collision APIs like “add this box to MoveIt”. If dynamic collision objects are needed, they should be managed internally by the exercise backend, probably through a semantic placement registration step later.

Current status is honest but incomplete:

• the SKU task data path exists,
• the feeder can describe incoming SKU boxes,
• the HAL can expose box and pallet metadata,
• the reference solution has a first row/shelf planner,
• syntax checks passed after the helper split and HAL changes,
• but full Academy runtime still needs more work for robust motion and collision behavior with mixed box sizes.

That is still progress. The exercise is no longer conceptually locked to eight identical boxes.

What’s next

Next I need to stabilize the SKU runtime path: rebuild and retest the feeder split, check that installed helper imports work in the ROS launch flow, and decide how much collision handling belongs in the first SKU demo.

The target is a clean student-facing task: boxes arrive one at a time, the HAL reports the SKU and pallet data, and the student writes a placement algorithm without touching Gazebo, MoveIt, or ROS topics directly.

Until next week 👋

GSoC 2026 · Week 9 · Coding period

Week 9: Syncing the palletizing exercise with upstream

After Week 8, the palletizing demo was in a good place visually: the UR10 picked boxes from the conveyor, carried them cleanly, and stacked them on the pallet. But there was a less visible problem underneath it — the feature branches had drifted from upstream JdeRobot.

This week was about paying that debt down. Less shiny demo work, more integration work: bringing the branches back onto the current upstream structure, resolving schema changes, and making sure the palletizing exercise still has a clean identity inside the platform.

Why the sync mattered

The palletizing work had been moving quickly on top of an older base. Meanwhile, upstream kept changing around it: new robots, new launchers, database changes, and a terminology cleanup that renamed the old universe/world layout.

Letting that gap grow would make every future test less representative. The exercise might work in my local branch, but not in the current RoboticsAcademy + RoboticsInfrastructure stack that it eventually has to live in. So the goal for the week was simple: catch up now, while the conflict set was still understandable.

The sync was done carefully instead of directly on the active branch. I kept a backup at the pre-merge state, performed the merge in an isolated worktree, reviewed the conflicts there, and only then fast-forwarded the main palletizing-exercise branch. That way, the working branch stayed recoverable during the whole process.

Worlds became Scenes

One of the biggest upstream changes was the database and launcher terminology.

Earlier, the project used universes.sql and a Worlds/ directory. Upstream moved to the newer structure:

• Worlds/ became Scenes/.
• database/universes.sql became database/worlds.sql.
• The old universe/world naming split changed into world/scene records.

So the palletizing launcher and database rows had to move with that structure. The world file now lives under Scenes/, and the launcher points there instead of the stale Worlds/ path.

This was not just a rename. Upstream had also claimed the IDs I had used earlier, so the palletizing entries had to be renumbered.

The current mapping is:

• exercise: 30
• world: 73
• scene: 73
• robot: 31

That is the set the Academy side now points to as well: the palletizing exercise is exercise 30, linked to world 73, which launches the palletizing scene and the UR10 suction robot.

A small note for future-me: some older notes still mention exercise 27 or universe/world 71. Those are historical now. The post-sync exercise identity is 30 → 73, with scene 73 and robot 31.

Converging with upstream’s MoveIt group parameter

Another useful outcome of the sync was around the MoveIt planning group.

Earlier in the project, the IFRA execution servers had a hardcoded planning group for the UR5. That broke the UR10 suction setup, because the palletizing robot uses the ur10_arm group. I had solved that locally by parameterizing the group name.

During the sync, I found that upstream had solved the same class of problem too, but with a different parameter name. Instead of keeping my local version and creating a long-term divergence, I switched the palletizing launcher to upstream’s final shape: ROB_GROUP.

So the UR10 suction launch path now follows the same convention as the current upstream robot launchers. The palletizing launcher passes ur10_arm, and the shared execution code stays aligned with upstream instead of carrying a forked version of the same idea.

That is the kind of sync result I like: not just “conflicts resolved”, but one more custom patch removed.

Rebuilding the Academy side cleanly

The Infrastructure sync was only half the story. RoboticsAcademy also needed to point to the new world and scene IDs, and the exercise needed to sit cleanly on top of current upstream.

So the Academy side was rebuilt as the standalone palletizing exercise on the current base, instead of carrying forward old experimental history. The important part is that the public exercise identity is now clear:

• Palletizing is its own exercise, not a hidden variant of Pick and Place.
• The database entry points to world 73.
• The exercise remains marked as a prototype while integration work continues.

This also keeps the project easier to review. The palletizing changes are focused around the exercise, its templates, and its database link, instead of being mixed with unrelated churn.

What changed from the student’s point of view?

Ideally, not much.

The student still sees the same idea: a UR10 with a suction cup waits for a box, picks it from the conveyor, and stacks it on the pallet through the HAL. The sync was mostly platform plumbing — paths, IDs, launch records, and robot configuration — but that plumbing matters because it decides whether the exercise launches in the real RoboticsAcademy flow.

The student-facing API stays centered around calls like:

• WaitForBox()
• MoveJoint(...)
• MoveLinear(...)
• SuctionSet(...)
• BoxDone(name)

That separation is the point of the HAL. The branch can survive a database rename or a launcher refactor without forcing students to learn about those internals.

What’s next

With the branches synced, the next step is to move the exercise beyond identical boxes and a hardcoded 2×2×2 target grid. The mentors’ direction is to make palletizing more algorithmic: different box dimensions, SKU families, and placement patterns.

So next week I will start turning the fixed-box demo into an SKU-based palletizing exercise.

Until next week 👋

GSoC 2026 · Week 8 · Coding period

Week 8: Polishing on mentors’ feedback

Last week the pick-and-place loop closed — boxes got stacked. But “it works” and “it works the way an exercise should” are different bars. The mentors went through the exercise and sent back a list of pointers, and this week was almost entirely about working through that list: the layout, the motion, the scene, the look. Less new machinery, more turning a rough-but-working demo into something a student would actually want to open.

Demo

The whole thing running after the polish pass — feed, pick, carry, stack, repeat:

Relaying the world

The first note was about the geometry of the workcell. Originally the belt ran across the front of the robot and the pallet sat behind it, which made the pick and place fight for the same bit of space and gave the arm awkward reaches.

So I rebuilt the layout around one idea: the robot works one end of the belt.

• The conveyor now runs straight out along world +X, with the robot at the near end. Boxes feed from the far end and ride toward the arm, stopping at a fixed pickup point right in front of it.
• The pallet moved to the robot’s right (−Y). So every cycle is the same shape: pick in front, swing right, place. A repeatable ~90° clockwise turn instead of a reach-over-the-shoulder contortion.

Getting the pallet distance right took a couple of tries. Too far out and the far row of the stack fell outside the UR10’s ~1.3 m reach — MoveIt would just report the plan as infeasible, the arm would stall at the belt, and the next move would drag the box across the conveyor. Pulling the pallet centre in to −0.88 m puts the whole grid inside the reach envelope while still keeping the deck clear of the robot base and visibly separate from the belt.

I also replaced the old table mesh with a plain wooden-pallet-on-a-stand built from boxes — cheaper collision geometry for the planner, and it reads more like an actual palletizing station.

Making the box stand out

A small one, but it mattered visually: the boxes and the pallet were both the same brown, so the stack blended into the platform and you couldn’t tell what had been placed.

I warmed and lightened the box colour to a kraft-cardboard tone and kept the pallet a darker wood. Now the stack reads clearly against the deck — obvious in the demo above.

The joint limits: “limit 4, 5, 6”

The main technical note was about the wrist joints. The arm was still doing ugly things — spinning a wrist most of a full turn, twisting the box around on its way to the pallet — and the ask was to clamp joints 4, 5, and 6 down.

Two things came out of digging into this.

First, a correction to my own assumption. I went in expecting to clamp all three wrists hard, but watching the motion, only joint 6 (wrist_3) was the culprit doing the visible box “swirl” — spinning the carton about the cup axis on the way over. Wrists 1 and 2 actually needed their range to reach the far row on the descent. So the fix wasn’t a blanket clamp: wrist_3 narrowed to ±120° to kill the swirl, wrists 1 and 2 left wide.

Second — and this is the bit I’m happier about — where the limits live. Last week I’d narrowed the shared UR10 limits to fix the 360° spins. But those limits are shared with the Pick & Place exercise’s UR5-family config, and clamping the common file to make palletizing tidy is exactly the kind of change that quietly breaks the neighbour. So I reverted the shared file back to stock (±360°) and added a palletizing-only joint-limits file that the suction launcher loads instead. Same effect for this exercise, zero blast radius on anything else.

That isolated file is where the “predictable” behaviour is actually encoded:

• shoulder_pan [−150°, +30°] — deliberately asymmetric. A symmetric range lets the planner pick either the clockwise swing or its counter-clockwise mirror; capping the positive side at +30° makes the counter-clockwise twin illegal, so the arm always turns the way the mentors wanted.
• elbow [0°, +180°] — elbow-up only, so the forearm never droops down toward the cells.
• wrist_3 ±120° — the swirl clamp.

None of these limit what the task needs to reach — they just delete the ugly redundant solutions from the search space so the planner is forced onto the tidy one. Same lesson as last week’s ±180° fix, applied with a finer brush.

Feeding the workcell to MoveIt

The other structural improvement: the planner didn’t actually know the conveyor or the pallet existed.

Up to now, the arm avoided them only because the hand-picked waypoints kept it clear — a single cruise height it lifted to, crossed at, and descended from. That works, but it’s fragile and it pushes obstacle-avoidance into the student’s solution code, which is backwards.

So I added a small behind-the-scenes node, palletizing_scene, that injects the conveyor and the pallet into MoveIt’s planning scene as collision objects when the stack starts. Now the planner routes around them natively — it knows the belt and pallet are solid. It publishes the objects as a planning-scene diff, in the same base_link frame the solution’s targets use, and re-publishes a few times so a late-starting move_group still picks them up.

The student solution and the HAL never touch the planning scene — it’s pure setup that happens for them. One nuance I had to handle: the pallet collision box is trimmed a few centimetres below the real deck top, so a box placed flush on the deck doesn’t get rejected as a touching-contact collision.

Making the motion predictable

Threaded through all of the above was the theme the mentors kept coming back to: the arm should move predictably. A student watching it should see the same clean cycle every time, not a planner improvising a different path on each box.

The joint limits do most of that work. The rest was in the solution’s motion shape:

• One cruise height. Every carry lifts straight up to a single transit height, crosses at that height, and descends straight down. No diagonal swoops that clip the belt.
• Dropped the return-to-home between boxes. It was a wasted sweep; the arm now goes pick → place → straight to waiting for the next box.
• Bumped the speed up. With the paths clean and predictable, I could raise the motion speed a good deal without anything flinging — the cautious crawl from earlier weeks wasn’t needed anymore.
• Cup centring. The suction cup doesn’t sit dead-centre under the tool flange, so I aim the flange a few centimetres short and the cup lands on the box centre — applied identically at pick and place.

The solution file itself got noticeably shorter and simpler in the process — a good sign that the complexity moved to where it belongs (the scene, the limits, the HAL) instead of living in the code the student reads.

What’s next

The layout, motion, and scene are where the mentors wanted them. Next is the vision side I flagged last week — a camera in the world and a detection node to replace the synthetic “box ready” signal — plus a proper standby pose over the belt so the arm waits in a sensible spot between boxes.

Until next week 👋

GSoC 2026 · Week 7 · Coding period

Week 7: Stacking boxes and getting the paths clean

Week 6 ended with the arm reaching the box but not yet picking and stacking reliably. This week the loop closes: a box rides in on the belt, the arm picks it, places it on the pallet in an ordered grid, and signals for the next one. Most of the week went into two problems that weren’t about “does it work” but “does it work sanely” — the arm taking absurd paths, and the student-facing code still talking raw ROS.

Demo

The full cycle — pick from the belt, carry across, place on the pallet:

Writing the placement logic

Up to now the box spawner cheated: when a box reached the pickup point it just teleported it onto the pallet to fake the result. This week the robot actually does the work.

The placement is a grid: 2 columns × 2 rows × 2 layers, eight boxes total. The solution walks the grid index by index — fill a layer row by row, then start the next layer on top. Each cell maps to a world coordinate, and the arm goes there. The motion for each box is the same shape:

1. PTP move to a clearance height above the pickup point.
2. Straight-line descent onto the box.
3. Suction on.
4. Lift straight up.
5. Carry across to the target grid cell at transit height.
6. Straight-line descent onto the stack.
7. Suction off.
8. Retreat up.

The pick and place heights are tunable constants, because the offset between the tool flange (what MoveIt positions) and the suction cup face isn’t a clean number — the cup is mounted sideways with a compound offset. One calibration pass in sim sets the height where the cup just touches the box top, and everything else is derived from that.

The arm kept taking the long way around

The annoying problem this week: planning would succeed, but the path was ridiculous. From the home pose to the pickup pose, the arm would swing a wrist joint a full turn — 310 degrees the wrong way — sweeping through the table on the way. Valid plan, stupid motion.

I spent a while chasing this in the wrong place. First I tried seeding the planner with a known-good pose before each move, which worked but was a band-aid. Then I tried giving the IK solver more time and more attempts — that helped it find solutions from far away, but it didn’t change which solution it picked, so the spin stayed. I even tried swapping the IK solver out entirely for one that picks the closest solution to the current pose. That one isn’t packaged for our ROS version, and an alternative added a heavier dependency, so I reverted both.

The actual fix was much smaller, and it’s about the joint limits.

A robot wrist at +52° and at −310° (which is +52° minus a full turn) are the same physical pose. The UR10 shipped with position limits of ±360° on every joint, so both solutions are legal — and the planner had no reason to prefer the short one. It just returned whichever it found first.

Narrowing every joint’s position limit to ±180° removes the long-way-round twin from the search space entirely. The arm can still reach every pose the task needs — you never need more than ±180° on a single joint here — but the redundant full-turn solutions are now illegal, so the planner is forced onto the short path.

That also explained why RViz always looked fine while my script spun: RViz seeds the solver from the live arm pose, which is near the short solution, so it rarely wandered. The scripted motion request had no such seed and hit the long-way solution every time — until the limits made it impossible for both.

The lesson I’m taking from this: when the planner gives you a valid-but-ugly path, look at the limits before you start swapping out solvers. Tightening the joint range was one line of config; the solver swap was an afternoon I’m not getting back.

The final setup is the stock IK solver with a longer timeout, and ±180° joint limits. No exotic plugins.

Moving the conveyor handshake into the HAL

The other cleanup was about where the line sits between the student and the plumbing.

The whole point of the HAL (Hardware Abstraction Layer) is that a student writing the exercise only calls simple functions — move here, grip, release — and never touches ROS topics directly. The motion and suction calls were already like that. But the conveyor coordination wasn’t: the solution code still had a class that subscribed to /box_ready and published to /box_done by hand. Raw ROS, sitting in the file the student is supposed to fill in.

So I moved it. The HAL now exposes two functions:

• WaitForBox() — blocks until a box is stopped at the pickup point, returns its name.
• BoxDone(name) — tells the feeder the box is stacked, which releases the next one.

The topic subscription, the publisher, and the bookkeeping that ignores duplicate announcements all live inside the HAL now. The solution file dropped its ROS imports and the whole coordination class — it just calls HAL.WaitForBox() and HAL.BoxDone(name) in the loop. Pure API, no plumbing.

One thing worth being honest about: WaitForBox() is not perception. The signal comes from the spawner node, which already knows where the box is because it put it there. It’s the right abstraction for getting the loop working, but it’s a stand-in for a real sensor.

That’s deliberate. Because the coordination is wrapped behind those two function calls, the synthetic topic can later be replaced with a camera near the conveyor that actually detects the box arriving — and the student’s exercise code doesn’t change at all. The function signature stays; only what’s behind it gets smarter. That’s the direction I want to take it: a static camera, real detection, and a reported box pose instead of a hardcoded pickup point, which would also let boxes arrive at varying positions instead of always stopping at the same spot.

What’s next

Tune the stack so the boxes sit flush on each other, then start on the vision side — a camera in the world and a detection node to replace the synthetic box_ready signal.

Until next week 👋

GSoC 2026 · Week 6 · Coding period

Week 6: The full loop — belt, box, arm

Last week ended with a UR10 that existed on disk and launched in a terminal window. This week I found out how many things between “it launches” and “it actually works” were quietly broken — and then got the full pick-and-place loop running for the first time: box spawns, belt carries it, conveyor stops, arm reaches in and picks it up.

Four things broke on first launch

The first time I ran the full palletizing stack, four things failed before the arm moved a millimeter.

The controller never started. The first error was symbol GzPluginHook missing — cryptic, but it traced back to the gz_ros2_control plugin (the bridge between ROS controllers and Gazebo) having been compiled against an older Gazebo version. On a ROS Humble system, the apt package for this plugin links to Gazebo Fortress, not Gazebo Harmonic — and Gazebo Harmonic refused to load it. Fix: rebuild the plugin from source with the right flag, tell the launcher to prefer it over the system one.

The move server crashed immediately. After that, the action server that handles motion commands exited with a file-not-found error — it was looking for a joint config file for the suction gripper that doesn’t exist (suction cups have no joints to configure). A one-line fix: tell it there’s no end-effector.

MoveIt refused to plan anything. Every motion request failed in about 2 milliseconds — fast enough to know it wasn’t even trying. The URDF said the robot was called ur5, the SRDF said ur10. MoveIt sees two different robots and refuses to proceed.

The suction cup’s contact sensor was on the wrong link. Gazebo merges fixed joints during world loading — so the suction cup’s sensor ended up reported as being on the wrist link, not the cup link. The attachment system that listens for “something is touching the cup” never fired. One line in the URDF tells Gazebo to preserve that joint and keep the links separate.

After all four: clean launch, arm holding its home pose, MoveIt ready to plan.

How the conveyor and arm talk to each other

Week 4 set up the conveyor belt and a box_spawner node that controls the box lifecycle. This week I wired up the handshake between the belt and the arm — the protocol that lets the robot know when to move.

The sequence goes like this:

1. The box_spawner node spawns a box at the feed end of the belt.
2. The belt carries it forward. The node watches the box position.
3. When the box reaches the pickup point — directly in front of the arm — the belt stops and the node publishes the box’s name on a /box_ready topic.
4. The robot’s solution code is subscribed to /box_ready. When the message arrives, the arm moves in, picks the box, and places it on the pallet.
5. The solution code then publishes on /box_done with the same box name.
6. The spawner sees /box_done, releases the belt, and starts the next box.

This keeps things clean on the student side — the exercise template gives you a simple wait_for_box() call that blocks until a box is ready, and a box_done() call to signal you’re finished. The student writes pick-and-place logic, not conveyor management.

It also means the exercise is self-pacing: the belt doesn’t send the next box until the robot says it’s done with the current one. No timing hacks, no hardcoded delays.

Fixing the suction HAL

The student-facing HAL was still a copy of the Pick & Place gripper HAL. It had three problems:

• At startup, it waited for a gripper controller that doesn’t exist on the suction robot — hanging forever.
• GripperSet() tried to move finger joints that also don’t exist.
• The list of objects the suction cup is allowed to grab was hardcoded to the Pick & Place props (blue_ball, yellow_box, etc.) — none of which match the dynamically-named box_<id>_<count> boxes the spawner creates.

The replacement is much simpler. SuctionSet(True) sends an on/off signal to the vacuum system. When vacuum is on and something graspable is in contact with the cup, the Gazebo plugin attaches it. When vacuum is off, it releases. That’s the whole API. One publisher, one message, no joint trajectory nonsense.

The graspable allow-list is now just "box" — a substring match that catches any box regardless of its generated name.

Why the arm wasn’t planning anything

Even with the stack clean, every arm motion request failed instantly. Buried in the output was this:

No kinematics plugins defined. Fill and load kinematics.yaml!

kinematics.yaml tells MoveIt’s planner how to solve “given a target position, which joint angles get me there?” The file had entries for the UR5 pick-and-place exercise (it’s shared), but nothing for the UR10 palletizing group. Without it, every pose goal fails before planning even starts.

Adding the entry — and giving it more attempts and a longer timeout, because the UR10’s longer arm has more configurations to search through — made pose goals start working immediately.

Which way does the cup face?

With planning working, the next question was orientation: which joint angles make the suction cup point straight down at the box?

My first guess was wrong. I assumed “cup down” meant pointing the tool’s Z-axis downward — the natural assumption. But the suction cup is mounted sideways on the tool flange, rotated 90°. So “cup down” actually means pointing the tool’s X-axis downward, which is a completely different set of joint angles.

Once I had the right orientation, I could start testing whether the arm could actually reach the box from above.

Straight-line descent kept failing

With the arm hovering above the box, I tried commanding it to descend straight down. The planner for straight-line moves (Pilz LIN, same as Pick & Place) kept refusing it.

The reason: at the cup-down orientation, one of the wrist joints sits close to zero degrees — a singular configuration where the planner gives up because small target changes would require wild joint swings. This is a known quirk of UR wrists at certain orientations.

The fix was switching planners for the descent step. Instead of Pilz LIN, I used computeCartesianPath — a different approach that stitches together tiny joint-space steps along the desired line. It handles the near-singular wrist just fine. Six consecutive 5 cm descent steps all went through cleanly.

The arm next to the box

By the end of the week the arm was reliably reaching a position close to the box on the belt with the cup pointing down — and the belt had already stopped and published /box_ready by the time the arm moved.

The remaining work is dialling in the exact height where the cup makes contact with the box top, and confirming the suction attach fires reliably. Once that’s calibrated, the full pick-place-repeat loop can run on its own.

What’s next

Finish the pick height calibration, confirm suction works end-to-end, then write the pallet placement logic so boxes actually stack.

Until next week 👋

GSoC 2026 · Week 5 · Coding period

Week 5: Swapping in the UR10 and cleaning up the framework

My mentors suggested upgrading the palletizing arm from a UR5 to a UR10 — the UR10 has a 1.3 m reach (vs 0.85 m) and a 10 kg payload, which is a much better match for a real palletizing scenario. That sounded like a one-word change (ur_type: ur10), but the rabbit hole went a bit deeper than expected.

The hardcoded group name problem

The three shared C++ action servers that drive arm motion — move, robmove, robpose — all had this:

std::string group_name = "ur5_manipulator";   // hardcoded in 5 places
move_group_interface_ROB = MoveGroupInterface(node, group_name);

MoveIt uses this string to look up the planning group in the SRDF. If it doesn’t match exactly, every motion call fails silently with “unknown group.” So a UR10 that declares its group ur10_arm in the SRDF would never plan anything — not because the geometry is wrong, but because a single string literal points somewhere else.

The fix I went with (matching an approach mentor Jesus used on a parallel branch) was to add a MOVE_GROUP ROS parameter with a default of "ur5_manipulator". The existing Pick & Place launcher passes nothing → gets the default → unchanged behaviour. The new UR10 launcher explicitly sets {"MOVE_GROUP": "ur10_arm"} on all three nodes. Five hardcoded literals replaced, one rebuild, zero regressions.

The arm swap itself

With the framework unblocked, the swap was mostly renaming and config edits:

• ur_type, ROB_PARAM → ur10 everywhere
• SRDF group ur5_manipulator → ur10_arm
• Joint limits and Pilz Cartesian limits swapped to the ur10/config/ paths
• The Gazebo spawn entity name and the world’s <robot_model_name> both updated to ur10_suction — these two must change together because gz_link_attacher looks up the robot by that name to know where to attach the suction grip

Naming things properly

At one point during the work I noticed we had a file called ur5_suction.urdf.xacro that was already describing a UR10 arm. That’s exactly the kind of confusion that causes real bugs — a future me would open that file assuming UR5 geometry and get UR10 instead.

So I renamed the whole family: ur5_suction.* → ur10_suction.*, and moved the URDF from models/ur5/ into a proper models/ur10/ folder. The shared generic xacro includes (ur.urdf.xacro, ur.ros2_control.xacro) stayed in models/ur5/ — those are arm-agnostic and Pick & Place relies on them — but the suction-specific file now lives where it should.

The ghost package bug

While validating the xacro I ran into a crash: Package 'ur5_gripper_description' not found. It turned out config/ur10/visual_parameters.yaml was imported from IFRA (the upstream framework) with all 14 mesh references pointing at that package — which isn’t installed in the RA image. The UR10 meshes actually live inside ros2srrc_robots/ur10/meshes/, mirroring the convention the UR5 yaml already uses correctly.

One bulk replace later, the xacro parsed cleanly to 575 lines. The arm would have loaded without meshes otherwise — a silent rendering failure that would have been genuinely annoying to track down.

Demo

Here’s the current state — the UR10 loaded in Gazebo Harmonic alongside the palletizing scene, with the arm skeleton showing in RViz:

Also this week: rectangular boxes

One detail I also got in: the palletizing boxes are now proper rectangular cuboids instead of cubes. Real-world palletizing almost never involves perfect cubes, and the rectangular shape makes placement orientation meaningful — which matters once the motion planning is written.

What’s next

The arm is in, named correctly, and plans against the right group. Next is getting the HAL’s SuctionSet wired up — replacing the GripperSet stub copied from Pick & Place with a proper vacuum on/off toggle — and then writing the actual pick-and-place motion logic for the palletizing cycle.

Until next week.

GSoC 2026 · Week 4 · Coding period

Week 4: A moving belt and a vacuum grip

Last week the Palletizing scene loaded but nothing in it moved — the conveyor was a static mesh, the boxes sat where I placed them, and the arm shared its gripper with Pick & Place. This week I made all three of those things untrue. Palletizing now has its own branches, its own exercise row, a conveyor that actually carries boxes, and a UR5 that wears a suction cup instead of fingers.

Giving Palletizing a home of its own

Up to now Palletizing had been riding inside Pick & Place’s exercise — sharing its card, its robot, its everything. That was the right call for standing the scene up quickly, but the moment the two exercises start to differ (and a suction gripper is exactly that moment), they need to be separable.

So I cut palletizing-exercise branches on both RoboticsAcademy and RoboticsInfrastructure, wired the exercise into the database as its own entry — exercise 27, universe 71 — and rebuilt the Gazebo world under that identity. The HAL templates I scaffolded from pick_place as a starting point; they’re stubs for now, but they give the exercise a place to grow its own student-facing API.

RoboticsInfrastructure@7d409c4

The conveyor belt

A pallet exercise where boxes don’t arrive isn’t much of an exercise. The Pick & Place conveyor looks like a belt but is a static mesh — so I replaced it with a real moving one using Gazebo Harmonic’s built-in TrackController system, the same machinery Gazebo uses to drive tank treads. The contact surface of the belt link gets a commanded velocity, and anything resting on it gets carried along.

On top of the belt I wrote a box_spawner.py node that owns the full box lifecycle:

1. A box spawns at the feed end of the belt.
2. It rides the belt to the centre.
3. The belt stops.
4. The box is placed on the pallet table.
5. The cycle restarts.

The belt speed is also controllable from ROS — there’s a bridge exposing it as a topic, so the speed isn’t baked into the world and can be driven from a node (or, eventually, from the exercise logic).

RoboticsInfrastructure@af25aff

The suction gripper

A palletizing robot doesn’t pinch boxes between two fingers — it grabs them by the face with a vacuum cup. So the UR5 needed a new end effector, and that ripples out further than you’d expect:

• A new URDF for the suction-cup variant of the arm.
• A new SRDF — and this one is genuinely different, not a copy. It’s arm-only: no finger group, because there are no fingers to plan for.
• A matching controllers config and a MoveIt launcher for the new robot.
• A palletizing_harmonic.launch.py for RViz.

I registered the suction arm as a new robot in the database and pointed the Palletizing universe at it instead of the Robotiq-gripper UR5.

The last piece was the grab itself. RoboticsInfrastructure uses a gz_link_attacher plugin to fake the grasp — when the gripper closes, it rigidly attaches the target object to the gripper link. That plugin had the robot model name and gripper link hardcoded to the Robotiq finger tips. I patched it to take both as SDF parameters, so Palletizing can point it at the suction cup face instead. Pick & Place keeps its old behaviour by passing the old values; Palletizing passes its own.

RoboticsInfrastructure@1623d8f

Demo

The conveyor carrying boxes, and the suction gripper picking them off:

What’s next

Next up is the HAL — replacing GripperSet with a SuctionSet that just toggles the vacuum on/off. The motion API carries over from Pick & Place; it’s only the end-effector verb that changes, finger pinch → vacuum on.

Until next week 👋

GSoC 2026 · Week 3 · Coding period

Week 3: Setting up the Palletizing World

This week I set up a Palletizing Harmonic universe inside RoboticsAcademy. Most of the work is reused from Pick & Place — same arm (UR5 + Robotiq 85), same MoveIt config, same controllers. What’s new is the scene: six boxes on a conveyor belt and a pallet platform to stack them on.

The changes are on my fork for now.

What changed

Four files in RoboticsInfrastructure, one SQL row in RoboticsAcademy.

The world file

Industrial/robotiq_description/world/palletizing_arm_harmonic.world — 317 lines. Most of it is copied from warehouse_arm_harmonic.world. The only new part is the six pickable boxes laid out in a 2×3 grid on the conveyor at z = 1.04.

The arm, conveyor, and table positions are unchanged so all the MoveIt frames and controller config from Pick & Place carry over as-is.

The world_file patch

spawn_robot_warehouse.launch.py had the world path hardcoded. I turned it into a launch argument with the original world as the default:

DeclareLaunchArgument(
    "world_file",
    default_value=default_world_file,
    description="Absolute path to the .world file to load in gz sim",
)

Pick & Place is unaffected. Palletizing passes its own path. 13 lines changed.

The launchers

Launchers/palletizing_harmonic.launch.py — sets GZ_SIM_RESOURCE_PATH and includes spawn_robot_warehouse.launch.py with world_file overridden and launch_rviz=false (RAM starts RViz separately).

Launchers/rviz/palletizing_harmonic.launch.py — a near copy of the Pick & Place RViz launcher. Same arm xacro, same MoveIt config, same RViz layout.

The SQL row

One row in database/exercises/db.sql:

71	17	68	False

Exercise 17 (Pick & Place), universe 68 (Palletizing Harmonic), not the default. This makes the new universe show up in the dropdown without any frontend changes.

There’s still a row needed in the database branch of RoboticsInfrastructure (universes.sql) to wire RAM to the launcher path — that’s the remaining piece.

Demo

Palletizing universe — Gazebo Harmonic with the UR5, gripper, and six boxes:

Conveyor belt:

The conveyor in the existing Pick & Place world is a static mesh — it looks like a belt but doesn’t move. For palletizing, boxes need to actually travel to the arm’s pickup point, so I wired up Gazebo Harmonic’s native TrackController plugin on the same model. It moves the contact surface velocity of the belt link. Combined with high anisotropic friction (mu2=800, fdir1 along the travel direction), boxes get dragged along rather than sliding. The belt speed is controlled by publishing a gz.msgs.Double to the plugin’s command topic.

On top of that I wrote a feeder script that spawns boxes one at a time from behind the belt, waits for each one to reach the arm pickup point, then spawns the next.

The arm doesn’t move yet — there’s no motion plan. The scene is just set up at this point.

What’s next

• Get push access to the main repos and submit upstream PRs.
• Add the universes.sql row to the database branch.
• Start working on the palletizing motion plan — pick a box, place it on the pallet, repeat for all six.