Playing with OpenScad
I’ve been wanting to get better about writing updates more frequently than I am currently. One of the big reasons for taking so long between posts is that I’m absolutely horrible at judging where exactly I should ‘plant the flag’ in a project, and get to writing about it. This is most evident in ORNIS, where I literally spent six months writing code, and didn’t write a single word about it until it was essentially a mvp. There were so many interesting posts I could have made during the process, which, if I had written about at the time, I could have fleshed out in greater detail. What instead ended up happening, was me wracking my brain trying to recall and remember why I made the decisions I did, and discussing them all briefly in one big post. The introducing post still turned out alright, but I definitly dropped the ball on it. My idea going forward, is that by having two projects going simultaneously, I’m forced to set a milestone for which, when I complete, I’ll switch projects. This should hopefully make it easier to keep the ball rolling on both the writing and technical fronts.
And on that note, let’s talk about KIWI.
So, for the design of kiwi, I the game plan is to use OpenScad. OpenScad is extremely different to my usual weapon of choice for modelling: SolidWorks. The biggest difference is that OpenScad is a purely textual interface (As opposed to visual), you need to actually write out all of the relations, sizes, and placements of your objects. If this happens to sound awful, don’t worry, it is. Every now and then, I’ll go out and read some online talks about OpenScad, and a small part of me suspects that all of the praise is part of some sort of collective gaslighting, an inside joke I’m just not clued in on.
Give me a ruler, a servo and solidworks, and I’ll have a bracket modelled in like 5 minutes flat. In OpenScad? An hour, maybe, if I’m feeling good. God help you if you’re trying to do an assembly, where you can’t place things relative to other objects. I would love to be able to write some form of “Place this object 20mm from this surface”, but nope, them shits is absolute. It’s awful.
Those who know me will probably be thinking they already know the answer. They probably think they’re so smart, thinking something obvious like: “Juraph clearly just wants to brag about creating a 3d model in vim.”, which I’ll admit is pretty funny, but no. I actually have real reasons (This time). I’ll attempt to condense my justification to three points.
- Models as plain text: I kind of like the idea of being able to regenerate the entire model of a robot with the change of a single parameter. It really opens up a lot of potential for rapid iteration, and test driven development (At least in simulation). Not to mention the benefits of being able to natively use git as the VCS on both the models, and the codebase itself.
- Interface forcing a workflow: People who have experience with Solidworks have probably already said 3 or 4 times while reading that you can already define parametric relations in Solidworks. But, OpenScad forces you to do this, kind of. You can still be lazy and not define things as relations/variables, but it’s a lot more obvious when you do make that mistake. This is important for my next point.
- Property based generative modelling: I’d like to present maybe one of my favourite papers of all time: Robot Leg Design: A Constructive Framework. This is one of those papers that completely changed how I thought about the design of my robots. The idea, on the surface, is pretty simple: select desired leg from a template, and then let an optimiser figure out the finer details. In this case, placement and sizing of the actuators, considering both the dynamics of the system, as well as the efficiency of the gait. It’s a pretty sick idea.
It’s kind of inspired me to try and integrate some sort of generative modelling for KIWI. A rough plan, in the long term, is to specify a few desired constraints (Inertia, height, mass), and have OpenScad generate a model that (roughly) fits these parameters. In theory, you could then attempt to verify and score these parameters in Gazebo, eventually converging on something suitable. I’m not sure if I’ll ever actually get that far before deciding to move on, but it’s a nice pie in the sky idea.
How’s it going so far?
I hate it. That’s fine, it’s not supposed to be pretty (yet). The goal is to get something I can throw into a simulation, as well as get a bit of a feel for OpenScad. As tempting as it is to spend a lot of time making it pretty, I’ll be re-writing almost all of it later on.
Next post will be about getting the model into sim, which isn’t very exciting, but it’ll be laying out a bit of what’s to come. Given how dense the first post on KIWI was, I don’t feel too bad about this, and the next post being a bit light. It’ll be getting very dense after that, as I’ll be going into a LOT of detail about the dynamics of the system, as well as what I’ll be doing for the control.