Mathematical Model of a Vacuum Cleaner Robot in Simscape Multibody

Physical tests on a vacuum robot are slow. Every change to the wheel position, spring or centre of gravity means a new prototype and a new test series. My thesis built a simulation model that answers these questions first, so fewer physical tests are needed.

• Theory. Kinematic and Lagrange dynamic equations of a differential-drive mobile robot.
• Model. A Simscape Multibody model of the robot with drive units, suspension, caster wheels, suction mouth and a wet-cleaning module.
• Contacts and friction. Using spatial contact force library and friction coefficient I measured on the real wheel, the contact forces between wheels, floor and obstacl are modelled .
• Fidelity check. The obstacle-climbing limit of the model compared with the measured limit of the real robot.
• Driving. Inverse kinematics of the differential drive in a Stateflow chart, which steers the model through a list of waypoints.

The robot has two driven wheels with radius R on one axle, track width L apart. It cannot slide sideways, and each wheel rolls without slip. The forward and angular velocity of the robot then follow from the two wheel speeds φ̇_r and φ̇_l:

To drive the model I need the inverse. A controller asks for v and ω, and each wheel gets its own speed:

The thesis also derives the Lagrange dynamic model, M(q)·q̈ + V(q, q̇)·q̇ = B·τ. In the simulation, Simscape Multibody builds and solves these equations itself. The derivation was there to understand what the solver does and which parameters matter.

Whether the robot climbs a step or gets stuck is decided almost entirely by contact forces. The model uses penalty-based contacts. Two bodies may overlap slightly, and a spring-damper pushes them apart.

• Wheels to floor. Sphere-to-plane contacts from the Simscape Multibody Contact Forces Library for the drive wheels, caster wheels, base plate and suction mouth. Each contact outputs normal and friction force on a bus, logged for every run.
• Robot to obstacle. Spatial Contact Force blocks between the obstacle and the body, wheels, casters and suction mouth. These blocks use the full part geometry, which matters for the curved suction mouth that lifts the robot.
• Stiffness and damping. Stiffness follows from the allowed penetration, k = m · g / d. Damping starts one to two orders of magnitude below stiffness and is tuned from there. Too high, and the solver slows down. Too low, and parts sink into each other.
• Friction law. The Spatial Contact Force block blends static and dynamic friction around a critical velocity. Below it, the effective coefficient is the static value. Above it, the coefficient falls towards the dynamic value.

Measuring the wheel friction

Friction coefficients are not standard values. They depend on the material pair, so I measured this wheel on wood. I placed a 60.8 g drive wheel on a wooden board and raised one end until the wheel started to slide. At that angle θ, the static friction coefficient is μ_s = tan θ.

These values go straight into the floor contacts. The kinetic coefficient is set below the static one, and both are mask parameters, so other floors can be simulated by changing two numbers.

• One parameter mask. Body and wheel dimensions, track width, component positions, centre of gravity, floor and obstacle friction, and suspension lever length and angle. Values come from the mask or from a script, so a test series can be reset in one step.
• Variant subsystems. The three suspension types sit in one variant subsystem and share one Simscape bus interface, so switching does not break any wiring. The wet module switches between spinning pads and a roller from the same mask.
• Solver choice. I used the Simulink Solver Profiler to find the states that slowed the run. The stiff contacts made ode23t the right solver.
• Limits. I also started a bristle-roller model with proxy contacts placed along a helix. Its forces did not yet match the measured values, so I kept it out of the validation.

The real robot had already been tested on steps of increasing height. It climbs 19 mm, needs several attempts above 15 mm, and gets stuck above 19 mm. I rebuilt this test in the model with a rectangular obstacle, a 3 mm edge fillet as in the test standard, and the obstacle height and approach angle as script parameters.

• The suction mouth hits the edge first. Its front radius lifts the body, so the mouth height sets the upper limit of what the robot can climb.
• The drive wheels then reach the edge. The suspension spring presses them down, and the friction coefficient decides whether they grip or spin.
• With too little momentum the robot stops at the edge, even at maximum friction.
• On the way down, the spring pushes the wheels to the floor and the body oscillates briefly. The settling time can be read from the logged data.

With the same suspension as the real robot, the model reaches the same 19 mm limit. The trailing-link variant gives the wheels more traction force and climbs 20.5 mm in the model. That is a design change the model can rank before anyone builds it.

I also modelled a braking test. A short-circuited motor becomes a sudden zero wheel speed, and counter-braking becomes a reversed speed for a set time. The model stopped in 7.8 mm and 7.19 mm on wood. The physical test had measured 13 mm and 10 mm on cork. With different floors and an estimated centre of gravity, this was a trend check, not a validation.

Moving sliders for v and ω by hand is a poor way to test a model. So I added a simple posture controller that drives the multibody robot through a list of waypoints.

• A Transform Sensor between world frame and robot frame gives the current pose (x, y, θ).
• A Stateflow chart holds the current goal. Its MATLAB function trackGoal computes the distance to the goal, √((x_g − x)² + (y_g − y)²).
• The chart outputs the angular velocity ω needed to reach the goal. The forward speed v is fixed at 0.3 m/s.
• Saturation blocks limit v and ω to what the real motors can deliver, and the inverse kinematics above turns them into wheel speeds.
• When the robot is close enough to a waypoint, the chart moves to the next one. The waypoints come from a parameter script and are shown as coloured discs.