Controlling a Robot on a Vertical Surface

September 2025 - December 2025

Most mobile robots drive on floors. Gravity pushes them into the ground, friction keeps the wheels gripping, and the control problem is mostly about not running into things. Put that same robot on a vertical whiteboard, held up by magnets, and the problem changes completely. Gravity is no longer helping you. It's pulling you off the wall.

This was the dynamics and control problem I worked on for the WIPERs project at BU, a team effort to build autonomous whiteboard-cleaning robots. My part was figuring out the physics: how do you model a robot that's fighting gravity the entire time it's moving, and how do you build a controller that can track a cleaning path accurately despite that?

The Modeling Problem

On a horizontal surface, a differential drive robot has a well-known dynamics model. Two wheels, each with a motor, and a constraint that the wheels roll without slipping. The math is in every robotics textbook.

On a vertical surface, three things change. First, gravity now acts along the plane of motion instead of perpendicular to it. If the robot is pointed sideways, gravity pulls it straight down. If it's pointed up, gravity fights the motors directly. The torque needed to hold position depends on which direction the robot is facing, and it changes continuously as the robot turns.

Second, the cleaning pads pressing against the whiteboard create significant Coulomb friction. This isn't the smooth, velocity-proportional damping that makes equations nice. It's a force that's roughly constant in magnitude and always opposes motion, with a discontinuity at zero velocity that makes the ODE solver unhappy if you're not careful about it.

Third, the center of mass isn't at the wheel axle. It's offset forward by about 30 millimeters, which means gravity doesn't just create a force, it creates a torque. The robot wants to rotate so its heavy side points down. This coupling between heading angle and gravitational moment is what makes the control problem interesting.

I derived the full equations of motion using Lagrangian mechanics with a pseudo-velocity formulation. Pseudo-velocities are a way of handling the nonholonomic constraint (wheels can't slip sideways) directly in the equations of motion instead of tacking it on as a separate constraint. You end up with two coupled differential equations for forward speed and angular rate, each containing gravitational terms, friction terms, Coriolis coupling, and the control inputs.

To verify the dynamics were correct, I ran an energy conservation test. Drop the robot with some initial velocity, no motor inputs, let gravity and friction act on it. The kinetic energy plus potential energy, minus the work done by friction, should equal the initial total energy at every timestep. It did, to within two microjoules. That kind of validation matters because if any term in your equations of motion is wrong, the energy won't balance. It's a much stronger check than just eyeballing whether a trajectory looks reasonable.

The Controller

With a correct dynamics model, the controller design becomes straightforward in principle: use the model to cancel out all the nonlinear stuff (gravity, friction, Coriolis terms), and what's left is a simple system you can control with proportional-derivative feedback.

This is called computed torque control, or PD+. At every timestep, the controller computes three feedforward torques: one to counteract gravity at the current heading, one to overcome friction in the direction of desired motion, and one to produce the desired acceleration from the reference trajectory. Then it adds PD feedback to correct whatever the feedforward missed.

The key insight is that without the feedforward terms, PD control alone doesn't work well here. A horizontal robot can get away with pure feedback because gravity isn't fighting it. On a vertical surface, the robot would sag constantly. The feedback controller would try to correct the sag, but it's always playing catch-up against a force that never goes away. By computing the exact torque needed to hold position against gravity and feeding it forward, the feedback controller only has to deal with small residual errors.

Getting the friction compensation right took some iteration. Coulomb friction has a sign discontinuity at zero velocity, which means the feedforward torque jumps abruptly when the robot reverses direction. I used a smooth tanh approximation to avoid numerical issues, but the transition width matters. Too wide and you lose the sharpness of real friction. Too narrow and you get oscillation near zero velocity. The final tuning was a compromise.

Results

The controller tracks a 2.8 meter figure-8 trajectory with position error under 5 centimeters, and typically under 2 centimeters once the initial transient settles. For the actual cleaning application, it follows a boustrophedon (lawnmower) pattern across the full whiteboard, handling the 180-degree turns at each row where the gravitational torque reverses sign.

The 48 hours I spent on this project split roughly evenly between the dynamics derivation and the controller tuning. The derivation was the intellectually harder part, but the tuning is where I actually learned the most about what the model was doing. Watching the torque commands during a trajectory tells you which terms dominate where. At the top of a figure-8, gravity compensation is working hardest. During turns, the Coriolis terms and friction compensation matter more. You develop an intuition for the physics by watching the controller react to it.

This was a simulation project. We didn't get to put the controller on real hardware, which I would have liked. The gap between simulation and a real robot on a real whiteboard, with motor backlash, imperfect magnetic adhesion, and marker residue affecting friction, would be significant. But the modeling and control framework is the kind of thing that transfers. The specific parameters would change, but the structure of the problem stays the same.