jaredjennings / dactyl-keyboard Goto Github PK

The bottom cover needs to be split into pieces of suitable size, for the same reason as the frame and sides, i.e. to work on printers with a smaller build volume and so each piece will only take an hour or two to print.

Connectors should be added, to make it easier to glue.

This may end up with a need to define the cover piecewise, as it is with the frame and sides.

Not a lot. Just like a tenth of a millimeter. And only on the sides of the nubs: the height of the nubs is about right.

All the work so far has focused on the right side. Now that it is nearing completion, also make the left side.

The northerly glue paddle of the thumb angles up to the thumb frame, and there's no place for a clamp to press on. Add it so this paddle can be glued.

Presently the eggcrate splitters are shaped sort of like eggcrates: wide, deep, but not tall; the bottom of each tray fits into the top of the next. Only they are stacked along the x-axis not the z. Their effect is to slice the bottom of the keyboard into long, thin strips. I've spent many evenings trying to tweak their thickness and offset (and the similarly shaped but pointier triangular-wave-oid splitters before them), such that there are no bites taken out of the leftmost or rightmost edge of the bottom, and no little bits hanging off the edge of any of the pieces, or even floating in midair. Every tweak takes like 10 minutes to show up, by which time I've moved on to something else and don't get back to it until 20 minutes later. And whatever OpenSCAD has to do to figure out how it's shaped, there isn't a progress bar for that.

I wanted to minimize the number of glue joints used for the bottom, and simplify them as much as possible, but the larger I make the pieces, the longer they take to print. And every piece (except for the first one, which is mostly the part of the thumb that sticks out) is as long as the whole depth of the keyboard (north-south). If I print it standing up to reduce the time and plastic taken up by printing support, the layer lines go across the width of the piece rather than along its length, making it weak.

So the bottom needs to be split along more than one axis. To just split it into rectangular pieces may not be the best, because four would have to meet in one place, and that place could be troublesome. With triangular pieces, six meet in one place. With hexagonal pieces, though, only three meet in one place. - Come to think of it, by alternating splits, like bricks are laid, you could have only three rectangular pieces meeting in one place. Meh, hexagons are cooler.

The thumb is hard-coded. I don't think it can be shoehorned into maps and lists like the description of other parts of the keyboard found in the layouts variable in layout.clj; but it should be factored and packaged so you can at least write another thumb, and say this layout has thumb A and this one has thumb B.

The bottom pieces need to be clamped together when they are glued. I just set two one on top of another when gluing, and they didn't quite mesh right and there are cracks. Such errors will certainly compound and result in a janky keyboard.

For pieces in the middle of the bottom, it's theoretically possible to clamp against something flat, although the vertical prisms are probably too big to actually do that. But pieces at the edge are angled up from the base toward the keyboard; there is nowhere for a clamp to gain purchase.

Two ideas I've had (thanks to other people at HackPGH) are to (1) make some kind of inverse of the side, whose outside is at right angles to the bottom; (2) add some kind of concave feature to the sides, where a clamp could gain purchase. It may in fact be necessary to do both: with an inverse piece made, why should it not slide against the side piece when they join at an angle? And this inverse piece should shy away from glue seams, so that if any glue gets out while the clamps are on, the inverse piece won't stick to the work.

In fact, up to now I've only thought of an inverse piece that encloses the whole side of the keyboard and is thus bigger than it; but maybe all that is necessary is some kind of straight-sided plug.

When I think of concave features, what I'm thinking of is a spherical dimple, maybe an inch around and a quarter inch deep. Once gluing is done, the dimple could be filled in in the Bondo stage (a thing I have not yet tried). But maybe if the feature is smaller in diameter relative to its depth - a quarter-inch cylindrical hole, perhaps? - less clamp slippage would occur.

Distantly a thought reoccurs. The first sides-to-sides connector I tried was some horizontal pins and holes. These failed miserably because the pins had to be supported, and the support was stronger than the pins and couldn't be removed. At the time, some people suggested I make holes on both sides and use pins of another material, such as metal. I kept iterating and came up with the hexagonal conical interface which is still unproven as a joint, but has turned out to be reasonably printable. But now imagine there are several holes that run horizontally through all the pieces of the bottom. Suitable interfaces are made for either end, with surfaces normal to the axis of the hole. The pieces are glued; interfaces and pieces are threaded on several threaded rods; washers and nuts are threaded on and tightened. Voila! Now, that only works for the present large block bottom. The original bottom was merely a curved panel, which would have feet of some sort attached; clamping things together in one axis when they are bowed out in another axis is a challenge. But the way we got to this bottom was by sidestepping the mystery of how the feet would look and how they would be defined.

Clear as mud what should be done, eh? But I had no other handy place to write these thoughts.

In order to make KeyPlace and ThumbPlace usable, they have been defined manually in OpenSCAD. But clj-scad can write OpenSCAD, and the manually written OpenSCAD contains redefinitions of constants defined in Clojure.

So make Clojure code that writes the definitions of KeyPlace and ThumbPlace, so that we can stop tracking manually written OpenSCAD.

I've printed a piece of the frame with the switch holes without nubs (see adereth#56). My Kailh Brown switches fit, but not tightly enough. Tweak the hole to be a bit smaller, test, and refine.

I didn't mind getting Clojure and OpenSCAD running, but it could be a barrier for someone. And if this program ever gets as flexible as I imagine (#37 and #38 are only the beginning, but probably not as flexible as https://github.com/HalFrgrd/UniversalKeyboardDesigner/blob/master/README.md), it would be annoying putting all the scad and stl files in the repo and keeping them up to date.

It's not that much easier or less developerish to get Docker running, so I guess the idea with making all this into a container would be to make a web app of some sort that would generate the STL files for a keyboard in your choice of forms: size of the finger part (number row? F-key row? extra Y and B keys?), shape of the thumb part (less keys, more keys, 2u or 1u keys, maybe manuform), shape of the sides (sphere, cylinder, octahedron, etc), column staggering amounts; and cache them so people can link to them with a really long URL, like you can with KLE.

This would cost money to host, and it is a great deal of work on top of the keyboard itself, and I don't know if anyone actually wants it, and I don't know if I'm the person to make it for them even if they do. But now, having written this idea out, I can safely forget it and think of other things.

The second bottom piece took like 2 1/2 hours to print, with what turned out to be not nearly enough support inside. Split it in more pieces.

Some of the 79 commits (at this writing) that I've done may be of general interest.

The half-circle connectors between sides pieces, and the sides-to-frame connectors, appear to be constructed incorrectly, because changing the downness of the sides has ... made these pieces work wrong.

I bought a Teensy LC instead of a Teensy 2.0, because I felt like a renegade. This could have interesting firmware implications, but those are down the road. Right now, it's not quite the same size. Make sure it will work OK. Exact location is not important because of the Adafruit extension I bought.

And I think my code can either put a bracket on every piece of the frame or none. Look and fix.

The Adafruit USB connector is coded, but it's ugly. Make its plate blend into the marshmallowy sides.

I've taken great care to make sure all the pieces are in the right places to fit together properly. Now, to show people the pieces, I want to explode them apart.

The way I would explain it is that each piece should be moved by a certain amount along the vector between the centroid of all pieces and the centroid of the piece. http://forum.openscad.org/Centre-of-Mass-td14707.html seems to suggest that you can't do this sort of thing in OpenSCAD, so it will likely necessitate using another program. But it should be automated so I don't have to worry about re-doing it manually all the time.

I'm interested in how you've split this up into pieces. I have a 3D printer with a small printing volume, so the only way I'd be able to print it would be in pieces.

I'd like to combine a Dactyl with the RollerMouse Red (https://www.contourdesign.com/product/rollermouse-red/). To do that, I think the roller would have to butt pretty close up against the thumb cluster, so that the keyboard wouldn't be too far away.

I think that to do that, it would be necessary to remove the marshmallow part on the front edge, and the height may have to be adjusted. I've looked through the source files, but I'm not sure where to start to accomplish these.

Can you give me any pointers about how I might accomplish that?

Thanks!

This should work itself out as the rewritten eggcrate box is integrated, but it's an issue.

I finally got a piece of the sides and a piece of the frame that fit together. The sides piece was too far down: the keyswitch was visible below the keycap. Yes, some people like that, but that wasn't the idea for this keyboard.

The bottom cover needs to be attached to the frame. Probably by means of tubes run up from the bottom cover, with holes that those brass threaded inserts can be pushed into with a soldering iron. Also screw holes in the frame.

Merge branches into master, and update the readme, so people can tell what's new and cool about my dactyl-keyboard.

After a keyboard exists, think about how it could be used on a bus, or in other situations where I have a lap but not a desk.

one of the holes for the stabilizers in the thumb is lacking most of one of its sides. find and fix

Get a Pi Zero W and a battery. Stuff them inside the keyboard. Run connectors (e.g. charging, video) to the edge of the keyboard. Figure out how to put some part in the left hand too so the right hand isn't markedly heavier.

The sides-frame connectors are too wide. You can't fit all the ones needed into the thumb part along with all the connectors between sides pieces. They only engage the frame-sides connectors along a fairly narrow strip. So make them narrower to match.

Interesting features have been added to scad-clj to enable the use-openscad-modules branch. In order to run with the modified scad-clj, I've added checkouts/scad-clj as a symlink to my scad-clj working copy. It'd be much nicer to be able to just write in the project.clj, "we need version 3000 of scad-clj," rather than continue this rigmarole and have to guide new users in it.

Make a hole for an RJ-11 (modular 4P4C) jack, and figure out how the jack will be stuck into the hole.

Add feet to the new bottom cover.

I've moved the sides up the keys some; but it appears the downness of the RJ-11 and USB jacks did not move with the sides, so now they are sagging off the bottoms of the sides.

Just got the Teensy pushed into the holder, and it doesn't quite close.

The screws I got are slightly too long to go through the frame and stop before the end of the threaded insert. So you screw the screw in as far as it will go, and it doesn't hold the frame tightly against the screw hole.

(And the hole in the plastic already wasn't quite deep enough for the insert to be pushed down far enough to be flush, by a half millimeter or so.)

Consequently the ... how you say, boss, in the screw-hole, needs to be deeper.

I've commented out tons of stuff, and it isn't valid anymore. Get rid of it.

Gather and photograph the plastic, and render the shapes, that preceded this point.

It could be because they are pentagonal, or because I've confused their radius and diameter. But drilling one of them out didn't work well.

The sides printed at 3mm thickness (well, the one piece I have) are satisfyingly solid but take forever to print. So I reduced the sides-thickness to 2mm. But then I printed the new, legs-having bottom, and it was a wide expanse of plastic 2mm thick, which turns out to be quite flexible. The possibility remains that when glued together several pieces of this stuff will be stiffer; but the possibility also remains that I'll drop it some day. On the gripping hand, neither will happen if the pieces take so long to print that I never have them in hand.

Anyway, I still haven't tried the sides at 2mm, nor the bottom at 3mm. Having these values independent might be helpful.

After eggcrating the sides-frame joints and printing once, I find that the waves have too great frequency.

There are several unfortunate naming decisions in the code.

Finger vs. thumb and key vs. thumb are one. I sort of like finger better, because after all the thumb has keys on it no less than the rest of the keyboard. I thought about having a configurable number of segments each with its own placement function, to get rid of all the hard-coding, but then decided this would only make sense if there were users with more than one opposable digit per hand. Not knowing of any, and not being one myself, this appears to be an unnecessary bit of (ahah) flexibility.

"Marshmallowy," "mallowy," "marshmallow," etc. were a more useful distinction when I was adding them into adereth's code and thinking of making them switchable; and the joy I felt at seeing them attached to my keyboard, and their roundness, reminded me of Homestar Runner saying, "marshmallow." But the adjective was always too long, and at this point it should go away.

There are three kinds of glue connectors at this point (well, two and a half), with another in the offing. The originals are stuck in dactyl.clj, as I recall to avoid circular imports. They need good names.

The vertical prisms yield pieces with points and edges. These tend to be exaggerated by the 3D printer, leading to surfaces that contact each other only poorly, and are difficult to improve by sanding.

Try adding more polys to the vertical prisms, to make them curvier; see if this yields a better fit.

When I made the eggcrate-splitters, I left some room between where the eggcrate splits the plastic in two pieces and where the holes are where you lace the pieces together while gluing.

One problem has shown up two ways: I printed the first bottom piece, and it had holes on its left edge. This means it isn't wide enough, and it also means the lace holes need to be closer to the split.

The sides connector on the frame side is great between rows, I think. It's well supported, and appears to have a good amount of contact area. But between columns, there isn't nearly as much space, because they are much farther apart toward the middle of the keyboard than at the top and bottom (like the Earth's lines of longitude). Also, due to the staggering, the line from the lower-right corner of one key place to the lower-left corner of the next is far from parallel with the general line of the side of the keyboard.

Something drastic needs to be done to the connectors on the north and south sides of the keyboard.

The keyboard presently extends below zero on the z-axis. Bring it up some.

Use τ everywhere instead of π. Multiply by fractions instead of dividing. These and others like them are practices I've evolved over the past however long, which means not all the code follows them.

The frame-sides connectors with their angled interface to the frame look good and are well-printable, but cannot be clamped against. Make them boxier.

The really small one (what, 2x2 finger) never really worked right. It wasn't a serious effort, just an attempt to reduce rendering times. But there should be a smaller size - what, 3 rows by 5 columns, or so? - it would probably work better, and some people would want it, and maybe its pieces will print faster...?

I went to print the sides, and found that some of the sides connectors are outside their respective sides pieces. That's no good.

The thumb frame doesn't have any connectors on it.

I glued together a couple of pieces with the current set of lace holes. The laces were easy to thread, and I think the joint may have worked (one of the pieces is much weaker than the joint so it's hard to tell), but the laces ran along the pieces more than across them, such that the force of pulling the laces was poorly converted into force pulling the pieces together.

If sharp points aren't good for the connections between pieces of the bottom (#42), then they aren't good for the connections between the sides either. And those darn cones never quite lined up right anyway. Use the vertical-prisms surface for the connections between sides, in the same way as they are used for the screw holes. Then any advancements made will apply to nearly all the connections in the keyboard. (The glue paddles are too small and thin to use this design.)

A piece of the sides and a piece of the bottom failed to fit together because there was an extra piece of plastic on the bottom of the sides piece, that probably didn't belong there.

A file is written for each finger piece (subset of columns), but none is yet written for the thumb piece. Fix.