Showing posts with label Openscad. Show all posts
Showing posts with label Openscad. Show all posts

Wednesday, April 8, 2020

The Polyhedra Project (video summary)

I finally got some time to edit old footage...and build a garden...and breathe, think, reflect.

Here is a video summarizing my parametric 3d printed magnetic polyhedral assembly tiles. 

About 8 hours in Adobe Premiere to do the bulk of the work, then a few hours to make final edits and export it.



Wednesday, January 9, 2019

Rhombic Enneacontahedron

Over a year ago I decided the next 3d printed magnetic tile based polyhedron I would create would be the rhombic enneacontahedron.

In the past I created shapes mostly by looking up the dihedral and face vertex angles from the internet. Only for the most recent one, the parametric pyritohedra/dodecahedron script, I generated the points of the whole polyhedron and manipulated them, before creating the individual faces as tiles. For the trapezohedra, some of the ones I attempted to create had the wrong angles, and it wasn't clear to me if the issue was in the angles I had gotten from the internet or if my OpenSCAD script contained some errors. I decided though that the right way forward would be to build the tiles as I did in the pyritohedra script, by creating the full polyhedron and then computing the angles for the tiles myself.

I had just learned about Conway polyhedron notation and considered that the right way to build this would be to use that concept. But I didn't end up getting a library for Conway polyhedron notation, or creating a library for these operators. Instead I did everything a bit less abstractly and elegantly than I'd have liked, but I think that's normal to expect for a first draft.

I switched from OpenSCAD to python at this point, because I find it impossible to do anything with for loops in OpenSCAD (highly inefficient and slow). For creating polygons in 3D space I used pyny3d, which is already integrated with matplotlib for drawing. And I use numpy for math stuff. I finally switched to python 3 for this and wrote every print statement incorrectly the first time...

We begin with the icosahedron:


For the icosahedron I started with a list of 12 vertices as listed on various places online.
Each of the below descriptions of vertices in format (x, y, z) expands into four vertices given there are ± options in two of the dimensions for each one.
(0, ±1, ± φ)
(±1, ± φ, 0) 
(± φ, 0, ±1)
Where φ (phi) is the golden ratio, 0.5*(1+sqrt(5))




The first goal is to truncate the icosahedron. I came up with my implementation of truncation by interpreting the picture and one line description from Wikipedia, which I'll include below, and is drawn on an example cube:


Truncate cuts off the polyhedron at its vertices but leaves a portion of the original edges.[10]

I describe truncation like this:
For each vertex, find every edge is is a part of, and create a vertex one-third of the way inward on that edge. The new shape's vertices are the newly created vertices.
The new shapes faces I separate into two categories.
The first category are created by drawing edges between all the new vertices spawned off a single old vertex. In our case, the icosahedron has vertices at 5-edge intersections, so these are five sided shapes (pentagons).
The second category are the truncated versions of the original faces. For each original face, consider each original vertex. That original vertex spawned some new vertices, but only two lie on this original face that we are currently evaluating. The new face that will replace the old face is defined by all of these new vertices corresponding with the old face, that still lie on this face.
We had triangular faces with the icosahedron, so with two vertices per original vertex multiplied by three original vertices, we have created six vertex faces (hexagons).



The truncated icosahedron is a soccer ball, shown above in red pentagons and blue hexagons.

Now we must run a join operation on the truncated icosahedron. Again, expanding from only the short wikipedia entry:

Join creates quadrilateral faces. 

That's not a lot to go on... To better understand it I considered a similar operation, kis:


Kis raises a pyramid on each face

Okay, so join is like kis without the original edges. The old vertices can stay put, but the new vertices, created in the middle of each face, need to be lifted. But by how much to lift them? And where to put them to center them on the face?

I had gone over the math for finding the vertex on the face, when I went over the math to define the dual operator. Luckily for me the pentagons and hexagons are regular, so I could just take the mean of the points in this case.

The insight for how to lift the vertices came from the symmetry. Some of the newly created quadrilaterals will go from one hexagon center point to another hexagon center point. To preserve symmetries, I assumed that all hexagon center points will be lifted the same amount. I drew a quick diagram to figure out the computation for how far to raise them in order to make all four points coplanar (otherwise, we don't have a valid face. At time of writing, this site which I enjoyed using in the process of learning about Conway operators, seems to have some nonplanar 'faces', so it looks very strange).

New quadrilaterals connecting old hexagon centers to old pentagon centers must also be created, utilizing two old vertices that come from the edge shared between the adjacent hexagon and pentagon. Since we finalized the height of the point raised off the hexagon center, and we know the two points from the shared edge are the same as they were before, the only thing to do is compute how far to raise the pentagon center along the norm of the pentagon face until it lies on the plane defined by these other three points.

To draw the faces I needed to keep track of which faces were adjacent to which other faces, so I created some dictionaries and populated them with simple for loops because I'm not concerned about optimizing my code at all given what I'm using it for.



The next step was to compute and print out the angles I needed to create a tile. This was just a question of identifying the right vertices, edges, and vectors and computing various norms and cross products.

For the tiles I moved back to OpenSCAD. I reused my rhombic triacontahedron tile code for the parallelogram faces (red). For the kite faces (blue) I created some new, but very similar code.

Here's the info printed out, there's definitely going to be some rounding error but not significant to my purposes.

There are two dihedral angles:
Red to blue faces: 159.4455573432933 degrees
Blue to blue faces: 160.81186354627906 degrees

The red parallelogram faces have an acute interior angle: 56.67993474152847 degrees
And the complement (computed just to check if correct, but not needed as additional info): 123.32006525847153 degrees

The blue kites are more interesting. The skinniest angles are the tips of the five pointed stars they create.
56.67993474152846 degrees

The opposite angle, which lies in the middle of those stars where they meet in groups of five, is close but certainly not the same angle:
69.7316519531762 degrees

It is a kite, so symmetric in this remaining dimension, and both of these larger angles are the same:
116.7942066526476

This didn't seem to match the info on Wikipedia and I'm also not seeing such a clear distinction between 'slim' and 'broad' rhombi. I wonder if I did something wrong, though so far everything is internally consistent for my construction. I wonder if there's an assumption I made that got rid of one degree of freedom....

Finally I needed some info about the edges. The red edges are all the same length. And, they match the length of the slightly longer of the edges of the blue tiles. The other type of edge is the ones that the blue tiles share with each other. I call this a 'short edge.' 

I computed a long side: 0.4339800705873414
And a short side: 0.36037602329028573

And the ratio of short to long as their ratio:
0.36037602329028573/0.4339800705873414

I ordered a few kinds of magnets in sufficient quantity (I need 90 faces * 4 magnets a face, but I might also double up and do 2 magnets an edge or 8 magnets a face). While I wait, I am 3D printing some tiles just to tape together and see if the angles work. So far it is looking promising.

parallelogram faces model, shown with magnet holes


 kite faces model, shown without magnet holes


They look fairly similar to the untrained eye...

Taped together with masking tape as a test....red parallelograms and white kites. They were all printed in white, and then I used a sharpie to color the parallelograms in red.



A five pointed star of kites.



Since these come together nicely, I think I have all the vertex angles and the dihedral angles correct.

I've always used either masking tape (testing) and magnets (super-glued into the slots) to construct these, but somebody who printed one of my designs and tried gluing them together noticed that there appeared to be an accumulating offset problem that grew as the shape was constructed and made it so it wouldn't close. It seems that you need to leave some flexibility in order to distribute errors (that come from the manufacturing process or mis-alignment during assembly). Some ideas I haven't tried include: putty, velcro.

Once I've had a chance to build the whole thing, I'll follow up with another post, and clean up the code and commit it to GitHub as well.

Wednesday, April 29, 2015

Spring Break CNC Adventures

While the UW students were off on spring break, I took some time to work on old projects from "The Big Project List."

I found a scrap of plywood which was just the right size to mill out Curio Shelf Revision 1.

The pieces before assembly:



Due to a mistake in the lengths of the dividers, the shelf curves outward in the middle. Not a bad look, but not a look I'd keep in Revision 2.



Another project is a bamboo magnetic board with a french cleat in a V shape for the wall mount. First I did a quick mockup in OpenSCAD to visualize it. The small piece here would be mounted on the board. The large piece would be mounted on the wall. In the first image, the wall would be on the positive x-axis side, and the board on the -x axis side.



Here's the finished cleat. It doesn't look very neat however it is not visible when the board is mounted. Now it is easy to remove or replace the board on the wall. This means you can use it as a screw organizer that you store on the wall.


Here it is with some things attached to it.


Thursday, November 6, 2014

MOARbots, the ESP8266, and more omniwheels

This project finally has a title.

MOARbots: Modular, Open-Source, Affordable Robots.

Progress on MOARbots is as follows:

I learned about the ESP8266 through Hackaday and decided to purchase a few. It is a $5 WiFi chip and programmable microcontroller to boot. I haven't been through the recently translated datasheet yet, but it seems to clock at 80MHz and have 16 GPIO pins, 2 of which are broken out on the boards I purchased. It will require tons of development to be usable for MOARbots but the community is very interested in it to make Internet of Things happen at a low cost point, so I won't be alone.

I decided to make a micromini version of my omniwheel bot, based around three Pololu motors I got for free. The motors are far too expensive at $15 to be part of the framework's suggested bill of materials, but for now this is a good project to test out my designs for small 3d printed omniwheels. I'm working through some designs, and here's a render of iteration #1.




















Hand forming steel wire made sense for circles, but not squares. I didn't want to take the better part of a month to build a CNC wireformer type machine, or to bother making simpler hand jigs for preset sizes or shapes, so I've rethought the design and will aim to use small finishing nails, which are cheap and widely available and don't need to be formed.

After the monthly Sector 67 meeting, a few people test drove the 2-wheeled cart. Despite the very simplistic control scheme (pre-programmed forward, left, right, stop routines), users were able to drive the cart pretty smoothly, even getting interesting drifting action at top speeds. The battery was barely drained even after a solid 20 minutes of driving, and with the addition of a heat sink the L298 motor driver was doing just fine (the heat sink is very necessary though). So this iteration of the cart is a success I think, and I will just need to buy some more L298s before I have everything I need to assemble 6 more.

Saturday, November 1, 2014

Omniwheel Robot 1

Before giving a talk at the university, I decided it would be a good idea to...spend 20 hours straight working at Sector on a omniwheel robot prototype. I only got a half hour sleep before the talk but I guess I must have been coherent based on the response from others.

See my slides on Google Drive at this link.

Here are some photos of the omni wheel bot.




















Omniwheel before assembly of beads. The wooden block is a jig for mounting the press fit gears on the motors. The vertical mount design isn't great, as weight of the robot causes the mount to flex downwards a little, which pushes the gears together more tightly, which increases friction. That will be changed in the next version.




















Some of the beads before mounting. I loaded them up on a piece of wire and coated them with Plastidip (black) or Flexidip (red, pictures on the full assembly below). It is better than nothing but still not a great solution. So far my best solution has been to skip tires entirely, and run the robots on rubber mats. I'm still looking for a good tire solution though.




















The fully assembled omniwheel bot. I tested it with the power supply, and it does move. It draws a bit more current than planned (5 amps or so) but I think with a little redesign I can make a lower current draw version.

I got a bin full of more stuff donated to Sector, including some really nice motors to play with. The primary goal is still ultra-low-cost stuff, so I will start looking into sourcing cheap motors. My framework will come with practical notes, including 'buying guide' type notes for some parts, as well as design files, code, and everything else.


Sunday, October 5, 2014

Robot platform in progress

Entire post got deleted while I tried to fix the alignment between the photos shown below. The Blogger WYSIWYG (what you see is what you get) editor is terrible for images, column layouts, etc. In short: I've been working on a lot of things recently, but haven't posted because posting takes time and effort and you need to get good photos of stuff and find a good stopping off point on those projects that never end.

The biggest thing I'm working on now is a robot platform that will be open source. The brain will be the Wixel and the cost will probably be in the $50-$60 to build it yourself. The gear/wheel/mounts prototype are shown below. To give you a sense of scale, the wheels are 9cm diameter and in the assembly shown below, the distance from the wheel to the motor terminals is about 7cm. The first goal for these will be to build seven of them myself and use them to run some fun programming competition aimed at adults/experienced programmers at Sector 67. Past that, I'll probably use these with an Arduino (in addition to, not instead of the Wixel) if I teach a robotics class this summer again.