Useful Household Items – Drip irrigation connectors

One of the first things I did when I purchased my Up! printer was to think about how it could be used to produce little things around the house.  To wit, I designed things like the electrical outlet cover plates, and other things with the ‘athome‘ tag on Thingiverse.

although it is very interesting to design many things that can be used in the home, sometimes it is not practical to actually print them out.  For example, the light switch cover plate, in order to print it requires quite a lot of plastic.  Given that these can be purchased for relatively cheap, since they’re so common, it’s not particularly cost effective to print at home.

But, other items make more sense, either because they are scarce, or so unique that you could not get them otherwise.  I recently pursued creating such an item.  It is the Flanged Connector.

There are several uses for this connector.  The most basic is to use it as part of a drip irrigation system.  You would insert this into the end of a piece of drip irrigation tubing.  Since it is hollow, it will allow water to flow through with ease.

When I designed it, I wasn’t actually trying to create something for drip irrigation.  I was after being able to easily connect drinking straws together.  I had purchased this book: Messing Around With Drinking Straw Construction.  I wanted to construct some structures with my daughter.  The method of connecting the drinking straws was to insert paper clips into the ends of the straws.  Where multiple straws came together, there were multiple paper clips interlocked.  It was that or pin, or tape.

As a general mechanism, it has the advantage of ease, and low cost.  Paper clips are readily available by the thousands, at relative low cost.

But, we found the technique to be a bit cumbersome.  The straws were not stiff enough, and the paper clips could not hold shape at the vertex, so it required multiple hands, or support to keep the structure from simply collapsing until the thing was entirely finished.

I wanted a better way to connect the straws, and at the time (around 2004), I was dreaming of a simple connector that I could stick into the ends of the straws.  I contacted an injection molding outfit, but they wanted a few thousand dollars to develop the design, do the mold, before anything was actually created.  I pretty much left that idea behind and bought quite a few Zome Tools instead.  That construction set worked quite well, and was more than sufficient to meet our needs.

Recently, I have been cleaning out the house, in preparation for a move, and came across the bundle of about 1,000 straws I had purchased so many years ago.  That bundle reminded me of the little connector that I wanted to create at that time.  Now, 7 years later, I actually know how to use 3D design tools, at least OpenScad.  Now I realize that what I want to create is a simple matter of a few odd shaped cones and cylinders, attached at various angles.

After going back and forth on a few design iterations with Sjoerd de Jong, there now exists a ready made library of routines to construct just about any type of vertex you want.  The Vertex Generator allows you to create vertices for a few well known solids, as well as create vertices of your own.  It utilizes some vectors that you pass to a routine, and it does the rest.

One of the things that I wanted from that library was the ability to separate the printing of the arms from the vertex math itself.  The library goes far down this path, and you could imagine replacing the ‘rod connectors’ with these tube inserts instead.

But, not needing the full generality of that library, I decided to start from scratch and create this imple connectors.  My requirements were that I could stick them into straws, as well as vinyl tubing.  I also wanted there to be some ready made connectors for common tasks.

I start with a straight connector, which can be used to simply join two pieces together in a straight line

This comes from the print_connectors(num) module.  Basically, the ‘num’ parameter is the number of connectors you want to be connected.  In this case, it was a simple matter of calling it: print_connectors(2);

You can call it similarly with any number of connectors.  There is a global parameter ‘standoff’.  This is the amount the based of the flanged connector is offset from the origin.  In the case where you have a high connector count, like 8, you might want to increase this size to accomodate the multiple connectors.

In this case, I used print_connectors(8); and ‘standoff=10;’.  This leaves enough space for the tubing to slide over the connectors, as well as get pretty close to the hub.

The ‘print_connectors()’ module is fairly handy when it comes to creating a set of connectors that are spread evenly around the hub.  There are some cases where you might like to specialize though.  Elbows are acommon connection type, as are ‘T’s and risers.  The library currently includes a module to create elbows.

     

Here, there are two elbows.  The first is specified with ‘print_elbow(angle=90, $fn=24);’, the second is printed with ‘print_elbow(angle=120, $fn=24);’.  In this way, I have specialized for the case of printing two connectors with an angle between them.  Really, this could be generalized to specify any number of vectors in a list, and let the print_connectors() module do the right thing.  That may be an exercise for the next round of these routines.

The really nice thing about this design is the hollow tubing.  Meaning, these are like pipe connectors, in that they will allow liquid to flow through the connector itself.  That ‘liquid’ can be anything.  One example might be colored water that is placed inside the straws, just to make things look interesting.  But, it’s just an open space.  These connectors could easily be used to route cables, with attached conduit.  You could use vinyl tubing to route wiring in a device, and put a little bit of elwire in there as well to light up the path.

One other Idea I had, for forming rigid framing, is to use vinyl tubing to connect things, then fill the tubing with some hardening foam, or epoxy, or something else that can first flow as a liquid, then harden into something much more strong and rigid.  That might be a great way to ship some simple structure, and assemble it without having to worry about long strong members.

Lastly, printing these things, although relatively inexpensive, is quite challenging.  The amount of overhang, and the tiny proportions, will challenge most DIY 3D printers of today.  Ideally, this would be injection molded, which was my original intentions.  But who knows.  Over time, being able to render such a design, inexpensively, and quickly, at home may become a reality fairly soon.  When it is more feasible, I can imagine the joy children and adults will have when they want to create a new toy for themselves, they go to their insta-printer, and out comes the results they expect.

 

 


Geodesic Math in OpenScad – Part 2 (of some)

Last time around, I introduced the very simplest concepts related to geodesic math, namely the spherical coordinates.  Now, let’s go one step further and utilize these spherical coordinates to do some calculations.  Here, I will reference the book: Geodesic Math and How TO Use IT by Hugh Kenner.  Although this book was originally written in the 70s, I found it to be the most descriptive when it comes to exploring the details of creating geodesic structures.

First of all, in order to form a geodesic structure, you can start by choosing a platonic solid.  For the purposes of the geodesics I’ll be dealing with, I use the Octahedron, and the Icosahedron.

One of the curious aspects of a platonic solid is that all of its vertices touch the circumscribed sphere of that solid.  That is the sphere the exactly fits the outside of all the points on the solid.

Given this funny nature, it is relatively easy to imagine extending various other points of the solid to meet the sphere.  Why bother?  Because each of the points extended in such a way represents another vertex, and when you’re actually building a geodesic dome, each vertex is a connection point for a stick or ‘strut’.

In the picture, we have an octahedron with its center at [0,0,0] of the cartesian coordinate system.

There are a couple of ways of specifying the coordinates of the vertices in the basic solid.  One is to simply use cartesian coordinates all around, thinking about the edge length, rather than the radius.  To do that, the mid-section might be easy enough:

In clockwise order, starting in the positive x/y quadrant: [1,1,0], [1,-1,0], [-1,-1,0], [-1,1,0]

Then you have to calculate the vertices that are up at the top on the z and at the bottom.  If you’re used to such things, you just pull out your handy dandy calculator and come up with the result.  If not, perhaps you’d prefer the spherical coordinates.  So, to do the same exercise in sperical coordinates, and instead of using an edge length, you use a radius of 1, and rotate around z for easier angles, you’d have: sph(0,90,1), sph(90,90,1), sph(180,90,1), sph(270,90,1)  And then, for the top and bottom: sph(0,0,1), sph(0,180,1)

Remeber from the last article, in spherical coordinates, sph(longitude, latitude, radius)

Using this technique, and using the sph_to_cart(), and sph_from_cart() functions, you can easily go between the two systems.  This is good because OpenScad knows about how to draw things based on cartesian coordinates, not on spherical coordinates.

The next step involves picking those intermediate points on the face of a platonic solid, and projecting them out to the circumscribed sphere.  As it involves a picture to demonstrate the technique, I’ll save it for the next post.

In the meantime, here’s the link to the current version of the code: Platonic Solids for OpenScad -v0.7

With this code, you can play around with the various solids, display in wireframe, take a look at duals of the forms and the like.  It’s all good preparation for the next round.


Lua Enters the House – Part Two

My experiences with OpenScad have been a good introduction to programmatic solid modeling.  OpenScad is a small enough language that I could comprehend and make good usage of it fairly quickly.  It took me about 6 months to run into the limitations of the language.  I would say hitting those limits coincided with my desire/ability to actually describe more complex forms.

I definitely want a more substantial language.  When trying to choose a language, I have considered a few design goals.

I want a language that can be utilized in multiple environments.  By ‘environments’ I mean embedded controllers as well as desktop machines.  I think an interpreted language will be better than a standard ‘binary’ deployment.  This makes for a more flexible programming environment as programs can be easily deployed by just sending a text string.  I want an easy connection to standard ‘C’ libraries.

I had considered JavaScript, as that’s widely used, and available in web browsers.  I had considered Python because it is very popular, and has tons of libraries available.  In the end, I chose Lua.  Lua is better suited for the embedded controllers I intend to use it on.  It is a fairly robust language, and it has the smallest runtime environment of those choices I have considered.  Lua also claims to be the fastest scripting language.  I don’t know about that claim, but considering it has been out in the open market for several years, leads me to believe they have learned quite a lot, and had plenty of time to make it solid and optimized.

So what have I gained?  One of the routines I have in my library is a some metaball calculations.  Basically, the function needs to sum up the influence of different ‘balls’ in a list.

function SumInfluence(x,y,z, ballList)
local sum = 0;

for i,ball in ipairs(ballList) do
sum = sum + MBInfluence(x,y,z, ball)
end
return sum;
end

This was not possible in OpenScad.  I did not have true function bodies, so I could not have a loop.  That alone is enough to make this language interesting.  What might be even more interesting is the ‘iterators’ that you find in Lua.  Iterators allow you to write code like this:

for v in IterateMetaballs({200,200,200}, balls) do
vec3_print_tuple(v);
end

An iterator allows you to simply write that for loop, and perform whatever function you want within the loop.  In this case, the iterator (IterateMetaballs) will keep returning values (the edge of the isosurface) until there are no more values to be returned within the specified volume we are exploring ({200,200,200}).

As functions are first class citizens in Lua, this iteration could be simplified even further, but it doesn’t need to be in this particular case.

Another thing I find interesting about Lua is the way in which it supports object oriented programming concepts.  It supports OO programming in a ‘meta’ way.  Unlike C# (my current ‘native’ language), Object Oriented concepts are not front and center as a MUST.  Lua supports tables as a basic data structure.  Tables can be used to store functions, and that can be the basis for a fairly simple object oriented system.  You can create more interesting constructs such as monads and the like.  At the same time, none of that is in your face up front, so the core language remains fairly small and fast.

For my own usage, I will stick to the simplest programming constructs.  Although more advanced functions and methods are possible, I find them to be unreadable.  I want to keep my code as readable as possible.

One thing that I would like to explore is creating a simple 3D modeling environment such as presented by OpenScad.  That is, a simple split window interface where text is in one window, and a simple rendering window is in the other.  This is fairly easy to do in Lua.


Lua Enters the House – Part One

The first time I ever thought about 3D design (beyond UI design) was when I wanted to get a custom part made a few years back.  It was a simple part that I would use to connect drinking straws together to form some simple structures.  At that time, the process of creation to plastic molded part was completely foreign to me, cost thousands of dollars, and simply was not pursuable.

Flash forward to 2010, and I purchased a CupCake from MakerBot.  While the machine didn’t work too well, I was hooked on the 3D prototyping in your home, scene.  I was still left with the desire to design some stuff though.  I am not a graphics designer, and I’ve never really used any visual design tools.  Even though experts make those things look really easy to use, I guess I just have a mental block to get over, and some hours of practice.  I am well versed in programming though, and luckily for me there was the OpenScad program, which looked really easy to pick up because it was a text based programming environment, rather than being visual.

Using OpenScad has been great.  I’ve been able to crank out literally more than 100 designs, in less than a year, using this simple program.  Granted, my designs are fairly simply, and most of them not particularly useful, but still.  For a guy that never did design work before, and was impeded by the scare of the learning curve, OpenScad has been a great introduction to design tools for me.

After using OpenScad for about 9 months now, I think I am getting close to truly understanding its limitations.  I would characterize the limitations, to my current design skills, in a couple of ways.

The first limitation is fairly mechanical, and relatively simple to solve.  Basically, under the covers, OpenScad utilizes a ‘set of vertices’ to get stuff done.  It works best when that set of vertices is pre-configured.  This is great when the number of vertices is small, and can easily be typed in by hand.  When it’s a larger set, that’s generated from an algorithm, you’re pretty much out of luck.  You can not dynamically create an array from within the programming environment.

This particular limitation has forced me to code up routines in such a way that dynamic arrays are not required.  Things are more incremental.  This might not actually be a very bad thing, but it is a limitation.  If OpenScad had a way to allow the creation of an array, and append to it, my life in OpenScad would be a lot simpler, and I would be able to create even more fancy designs.

The other limitation is more subtle, and languagey in nature.  You do not have ‘true’ variables.  You can in fact assign a value to a subtree of a graph, but there is not a concept of a variable that has scope outside the subtree, which can be easily changed.  This is challenging if you want to do something in a loop where the variable state needs to be saved/incremented between iterations of the loop.  It is possible to use the ‘assign()’ mechanism.  It just makes for some very odd looking/feeling code.

The last blocker is the fact that ‘function’ is more like a macro.  You can create a function that returns a value, but it can not have any statements other than the return expression.  That means that I can not create a function that does any real amount of calculation, or iteration, and return a result.  You can get around this for some functions, by creating more functions, but ultimately, you’ll run out of room, and need a simple loop construct, and it won’t be there.

All these ‘limitations’ are simply the constraints of the system.  They don’t detract from OpenScad in the least.  They do point towards an alternative direction to take things though.  Now that I understand it more, I view OpenScad in a different light.  Instead of being my end all be all environment where I do all of my design work, I view it like this.  OpenScad is just an exchange format, and there so happens to be a convenient OpenScad viewer attached to it.

When I think of it in these terms, I’m a little more free to come up with a more evolved design chain.  Instead of trying to make OpenScad do everything I want, I will just use it for the things it is good at.  The best thing it brings to the table are the connection to CGAL to create .stl files that represent the CSG commands that are used within the programs.  That is, OpenScad gives you the ability to use CSG to construct models.  Then it conveniently turns those models into .stl files which can be printed.  That’s goodness.  Feeding this machinery is what I want to change.

In steps Lua…

<End of Part One>