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?: 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.
In this latest update, ORNIS now supports element selection! This required a bit of re-thinking of how messages are handled in the front-end, but I’m quite happy with how it turned out. One of the downsides to working intermittently on a project is that one tends to run into a lot of “Wait, I’ve already solved this!”, and this update has a few of these instances. The big one was almost re-inventing “msg_tree”, essentially a nested tree data structure I created for the service interactions.
In the last post, I mentioned I was having reservations about OpenScad, and its suitability as CAD software for KIWI. The primary source of these reservations was simply that after making only minor headway, each operation had become so tedious. Simple things like a bracket for a servo was becoming far too much trial and error for my liking. Initially, I thought I’d be able to simply take some measurements of my part before I begin modelling, save them as variables “servo_width, servo_height” or something similar, then use these dimensions to define our extrusions/cuts for the servo mounts.
One of the earliest requirements I laid out for ORNIS was the ability to send/recieve service calls. While the ‘ros2 service’ interface may be convenient, it is cumbersome to say the least. I have had countless issues with attempting to fill out larger service requests via the CLI, only to accidently mess up the indentation. The resulting failure to request always strikes a nerve.
Ironically, my initial implementation of the service interaction had the exact same issue.