Friday Facts 7: A 2D physics engine in Processing (Java) and the Sunk Cost Fallacy

I have a robot dog being operated on by the Students at Alpha Secondary school in Burnaby, BC, as part of a work experience program. The goal is to make the dog walk as good or better than Spot Micro. Obviously this is not done in a weekend. How do you eat an elephant? One piece at a time. The current plan is to tackle things in order:

  • get it to turn on (done!)
  • move each motor individually (done!)
  • move them together (done!)
  • make it stand up and sit down (working on it!)
  • teach it to roll over and recover from a fall
  • teach it to walk

In a sense I’ve delegated all these steps to the students. Which frees me to do the part that needs experience – making tools that will empower them to do the hard steps at the end.

I don’t want to break the robot because it’s expensive to fix. Therefore I don’t want anyone to drop the robot hundreds of times while testing it. Given the tools I have, what can I do to test the robot without dropping the robot? The same thing I’ve done with all my robots – simulate them! But I’ve never used a phsyics system in Robot Overlord before.

I already have all my code and development tools in Java, so my first instinct is to continue in that direction. I didn’t find any up-to-date physics engines that work in Java. JBullet hasn’t been updated since 2016. Other engines I found were Java ports of C libraries. I don’t have links to them any more but those I found were stale and had no “contact us” system. Two solutions present themselves:

  1. Write my own physics system in Robot Overlord from scratch
  2. Install Gazebo on a linux system, ?, profit.

For your consideration, this is my attempt at number 1.

2D physics with circles and boxes in Processing

This is the first time I’ve had to simulate things with physics in Java.

This is a 2D physics engine written in Processing 4.0b. At tag 1.0, it looks like this:

Much help and inspiration was obtained by reading the code for Impulse Engine by Randy Gaul. Do your homework!

It took a day to write the drawing of shapes and 13 more to debug the physics up to this point. Here’s what it looked like at the half-way point:

The hope is to extend this into 3D, add constraints (think bones connected by joints), add friction, and then make physically approximate ragdoll models of the Spot Mini. They can be dropped, kicked, drop kicked, and beat up over and over until the simulated walking gets them up and balanced. Then the simulation can be tied to the real machine and our goal should be within sight if not in reach.

The sunk cost fallacy

Initially I didn’t even consider option no 2. The cost of setting up a linux box or partition, learning Gazebo, installing the robot model, unknown further mysteries tbd… I choose the devil I know over the devil I don’t!

Discord user M2710 DM’d me to ask “why don’t you just [gazebo]?” and made a compelling case that it might be easier than running my own physics engine. I couldn’t immediately prove the idea wrong so I have to consider it might be right. I’ve booked a day in the near future to try Gazebo and Webots. Look for that in an upcoming FF.


If you have experience with Gazebo or Webots, share your story with us on the Discord channel. we really want to eat your juicy brains know what you know.

If you have java/physics skills and you think you can get the Robot Overlord features (3D, constraints, friction, physically approximate ragdoll models of the Spot Mini) working, DM me! I want to help you help me. Make me an offer, I’m eager. I only have so many hours in the day and I need your help.