Alright, third post in a row where I switch to a new build system. I know it’s not a great look, but I swear this is the last time.

With this new model in Build123d, I’m finally settled on a library that seems to scale gracefully (roughly linearly) as assemblies accumulate complexity.

Why the switch?:

1. Assemblies become unwieldy Previously I touched on the fluent programming style, and how it felt like a substantial change from the OOP style I’m used to. As it turns out, this API started to feel clunky and difficult to introspect on once the model got complex enough. Build123d’s approach allows me to easily segment, re-use and modify chunks of operations.
2. Link placement via constraints In CQ, parts are connected to assemblies using a system of constraints. This made placing components in assemblies far more difficult than I feel it should have been. Build123d allows me to link things using static joints, with which I can simply declare: “This part goes right here”, no fuss. It’s a pretty great system.

Almost complete design:

Some thoughts on the design

It’s not 100% yet, but it’s close enough for me to get printing. There are a number of things that I think require some tuning, most significant being the placement of the encoders on the outside of the wheels. I’ve thus far eyeballed the distance, and may need to be modified based on how they perform.

The second is actually the placement of the IMU. It currently sits between the two wheels at the base of the arch, at a significant offset from the axis of rotation. I have seen a few other inverted pendulum designs place the IMU directly on the axis of rotation, I assume these designers are attempting remove any error propagation that may occur from having the IMU encounter coupled displacement with the rotation. This doesn’t line up with my (admittedly limited) experience with IMU’s, as I am fairly confident the offset will actually assist in providing additional state information, which I can pass to an ekf to provide better estimations.

Interesting ways to manipulate geometry

A recent addition to Build123d is something called algebra mode, which provides an alternative way to construct geometry. There is also a supporting set of definitions, which covers the ‘rules’ of how elements of different dimensions can be manipulated. This alternative notation allows for a far less verbose notation, as you can see in the Introductory examples. This was added very recently, essentially after I’d completed the bulk of the design for KIWI, so I haven’t had a chance to play around with it. However, I can very see how these kind of operations would lend themselves, well for building inertia based solvers for constructing a robot. I will no doubt be attempting to leverage this either in the later parts of KIWI, or maybe the project after, we will see.

What’s next?

From here, we move onto our rapid iteration workflow for the chassis. This is where we print a part, figure out what hasn’t translated well to reality, adjust, and re-print. Definitely the most time consuming part of the build, but far from the most difficult.