Producing More Modules

I've spent the last several months producing, single handedly, a further 5 Omni-Pi-tent modules. This has been a time consuming process, but in the few breaks from soldering and part assembly that I've had I have been able to work on our self-assembly and Dynamic Self-repair simulations in V-REP. I'm using this post to provide a few updates on progress, share a few lessons taught by the cruel hand of repeat production, and make a few notes on the topic of work soon to be published.

Port faces for 5 modules being assembled

The 3D printing itself is a pretty hands-off process, while all parts have been designed such that they can be produced by a hobbyist grade printer (indeed the prototype module demonstrated at TAROS 2019 was entirely printed by such a machine, a Robox), the Department now has some Stratasys F170 printers which can run whole batches of parts at once and pretty much never produce a warped print which would require re-printing. With the ivory coloured ABS material they make some wonderfully smooth gears, oddly enough all other colours give rougher textured parts, which mate with minimal friction and seem able to stand up to pretty substantial forces with ease.

Worm and bevel gears printed in the slippery ivory coloured ABS material

The trouble with the F170 printers is the GrabCAD software, it's not too bad software as such but lacks a lot of the controls one would expect in an stl slicer program. Thankfully it recently got an ability, described in software as "body thickness", to let the user adjust the number of perimeter layers around the infill. Extra perimeters are a weight efficient way to significantly strengthen a 3D printed part, plenty of online sources show how several extra perimeters tend to give strengths almost as good as solid for only perhaps a quarter of the mass of plastic. Until this feature got added to GrabCAD it couldn't be trusted to produce certain small cogs, such as those to drive the omniwheels, and a few other parts designed to have minimal mass but subject to potentially a lot of wearing over time. GrabCAD still goes over the top on the amount of support material used, which slows down printing and costs quite a bit of money on support material. With some careful trial and error it became clear that the weight and perimetering profiles we had used on the Robox systems could be reproduced within GrabCAD, once GrabCAD added the "body thickness" options, albeit slightly heavier for most of them.

A comparison of gears printed with and without extra perimeter layers, note the difference between the nozzle path used for the perimeters on the white gear and the infill pattern on the yellow gear.

When a printer job is set up with the GrabCAD slicer to use either an ABS or ASA material profile then should you decide to switch materials before production the slicer reverts the files to default settings for things such as density of infill and number of perimeters (specifically high density but not solid infill and only two perimeters), this can be a pretty dreadful default for the applications some parts are designed for. I would hope that future software versions would keep modified print settings the same when switching between the material to be used. As a final note about GrabCAD, in one or two places, particularly where 3D printed parts are designed such that there is a hole within a sloping surface into which other items slide such as behind the spikes on the outer rim of the docking ports, it tries to thicken thin walled regions. Unfortunately it does this to some sharp edges which would be better cutting off early than made thicker near their tips, thickening them like this prevents other parts slotting into place, hence some hand filing is needed afterwards in a small number of places.

Diagrams showing, on the CAD model of one of the printed parts, the approximate effect of GrabCAD's automatic thickening of thin walls. As another parts slots into the hole with the sharp edge filing was necessary after printing.

PCB soldering has gone well, a mixture of handsoldered through hole parts and hand placed SMD parts with pump-fed needle-applied solder paste. Over time the difference in speed to attach components in the two ways becomes astonishing, from having never SMD soldered before one finds within a few tens of sessions practice that the full process from peeling the plastic backing off the paper reel, turning the component the right way up in tweezer tips if it fell out at an unusual angle and then putting an SMD component into place atop the pasted pads, can be reduced to around 20 seconds per component. Soldering with an iron for through hole parts always seems to take a large fraction of a minute per pin, not counting the time needed to first insert the part into the through holes and sometimes blue-tack it from "above" to keep the part stable while soldering.

The Central and Port PCBs for a single module

Unlike the first prototype the five modules in production now, and the second prototype (mostly white) built in summer, there are no free hanging parts or wires soldered to boards. Instead the boards and components each have headers soldered on which connect to cable assemblies, for the small parts such as microswitches which have to be scattered in very physically specific locations tiny shim PCBs join the switches to header connectors. This has made assembly much faster and much less prone to solder joint breakages.

Charging of the NiMH batteries has also been made a quicker process, the whole lot can now be charegd in situ in a matter of hours, avoiding a laborious battery removal and reinsertion process.

The temperature over time of a module's 8 cell NiMH pack being charged in-situ within the confines of the thermally rather insulating core of the robot, note the only minor rise in temperature. The sharp spike is unexplained, it affected both sensors, shown in blue and red, located at diffferent locations around the battery pack but seems surprisingly brief for a temperature change.

In the project overall we've been running simulations of self-assembly under various circumstances, particularly concentrating on scenarios where the Omni-Pi-tent platform's unique set of capabilities is essential for effective performance. This has involved getting V-REP to run on our university supercomputer (the University of York's Viking system), so we can gather statistical data from repeated runs with randomised strating conditions. Clusterising V-REP is in some ways straightforward and in others extrememly bothersome. V-REP 3.6.2, the latest version during autumn when the cluster work was begun,doesn't seem compatible with any non-debian based linux distro, the supercomputer is indeed not debian based. V-REP 3.5 on the other hand runs, mostly. I am not certain of exactly how it happens, but it appears that multiple V-REP instances running on the same machine have some form of conflict which prevents the lua scripts in more than one of them from writing out to a text file, it also prevents some of the instances running in parallel from terminating their simulation when sim.stopSimulation() is called. Fortunately however this conflict appears not to occur if the instances are run on separate cluster nodes, note that is nodes, not cores, running sims on the same node but separate cores triggers the conflict again. With the number of nodes available we can run about 40 simulations at once in parallel, the whole batch usually completing within under 12 hours. By that method we've gathered data on self-assembly performance for a variety of shapes in arenas of varied sizes, a paper on a new method we have developed should be coming soon.