• Development Team Report / February 2015

    by  • February 23, 2015 • News • 1 Comment

    1. Handibot Hood

    We’re just finishing up a hood-type enclosure accessory for Handibots (for v1.0 and the upcoming v1.1). We’ll call it the “Handibot Hood”. This enclosure helps contain flying debris and somewhat reduces noise from the router. It should be available as an accessory in the Handibot store later in the week.Handibot Hood

    To use it, you’ll remove the existing front guard and drop on the new hood. It snaps on and off and it covers the entire front compartment area. In a pinch, it will fit over the existing v1.0 face guard without removing the guard so that you can have both options. But it does not fit tightly in this configuration.

    The Hood is an attractive accessory. It was designed by engineering intern, David Preiss. The parts for it make full use of digital-fab techniques and CNC machining. We plan to produce the blue end-pieces here using Handibots mounted on the next-to-be-released “Crawler” attachment. We believe it’s good for us to use Handibots in production to learn as much as we can about them, but we’ll probably cut the larger, clear acrylic panels on a big tool.

    Hood End Piece

    Hood End Piece

    For those interested in DIY fabrication or in modifying the design: the digital models (as STP files) are posted on the Handibot GitHub site; we’ll also post CAM files there soon. It will be straightforward to produce parts for the Handibot Hood if you have a ShopBot Desktop or larger CNC.

    With only your Handibot, it will take careful tiling because plastic parts tend to highlight any mismatches of tiles. Machining the end-pieces is your first step. These mirror-image parts fit a double-tiled work area of ½” HDPE. If you want to round the corners over perfectly, you will need to do an additional manual operation with a round-over bit (the type with a bearing). To do a really nice round-over, you will also want to machine a set of jigs (files also to be included) for use with the round-over cutter.

    Cutting the clear acrylic with your Handibot will involve a larger area of tiling. Whether you cut the acrylic on a large tool or on your Handibot, bending the clear acrylic piece will be a challenge if you are not set up for it. We’re testing some methods to do the bending reliably with simple tools to make it more feasible for DIY one-offs. We’ll be posting additional documentation and suggestions for DIY fabrication of these parts on the GitHub site after we get the accessory up on the store.

    2. Modular Electronics

    I’ve have had a number of questions about our plans for the electronics that underlie the new FabMo Platform for motion control. The most recurring one is: why not put the embedded motion component (what we refer to as G2) on the same hardware board as the single board computer (SBC) in order to simplify the project and perhaps reduce cost? A more technically specific version of the question wonders about using the Programmable Real-time Units (PRU’s) of the existing Beagle Bone Black (BBB) as an already available component for our embedded motion core, these already being within the micro-controller on the SBC.

    All good and reasonable suggestions and the BBB approach might be very interesting. However, our thinking is that it would probably be more expensive for us to combine all the functionality on one board at the moment, given that we are not yet working at very high volumes. It is exactly the high volume economics of the current SBC’s that allows their attractive pricing and makes them available to us as modular components. Rolling-our-own at this point is probably just a little premature. Locking into a specific chipset might also prove restrictive in terms of further development. It could also mean that those participating in collaborative open-development for other tools would feel limited by our specific choices.

    While the BBB/PRU possibility seems particularly appealing, in order make it compatible with Handibot and ShopBot hardware, we would need to make an entire new board or produce an additional cape-type board providing the connector compatibility, output buffers, and input isolation that we need to hook up to our tools. It would also mean needing to develop a new motion core and largely abandon the great work that has been done in the grbl > tinyG > G2 evolution of motion software specifically for fabrication.

    Our thinking is that by sticking with the three modules – SBC, motion card, and interface-board-with-drivers – we will preserve a lot of flexibility. We will be able to readily swap in new hardware modules at each level as components with more capability and better cost become available. Importantly, the system will be compatible with a wide range of existing equipment and be very accessible to other developers using off-the-shelf development hardware (e.g. a BBB or RPi for the SBC, and Arduino Due, TinyG2, or FabMo board for the motion card, and a Handibot, ShopBot, or TinyG2, alternative, or custom motor interface board for the output component).

    We plan to continue using USB for the short link between the FabMo-Engine on the SBC and the FabMo-G2-Core on the motion card. There are some more direct alternatives for serial communication, but USB provides a common interface standard and has the side-effect of providing a layer of flow management and corruption protection before the final motion stage. It also allows easy alternative connections in and out of the system for those using it in other ways.

    We’re expecting the arrival of a batch of beta, v300 control cards this week and expect more info on control system progress and availability in next month’s report.

    3. Changing the Size of the Handibot Work Area

    Nearly everyone using a Handibot has some idea for how a change in the work area and footprint might be useful. Indeed, a concern over the attractiveness of larger work area vs. the trade-off of bulk has been with us since the first conceptual sparks of Handibot.

    We wanted the tool to be small and light, so as to be readily portable, but we wanted it big enough to handle some real cutting – say of the jobsite type – without needing to be repositioned for standard lumber. For its size and weight, we wanted the tool to have a no-compromise, rigidity within its work envelope, so that aggressive machining was possible for a range of materials.

    Frankly, Handibot ended up being heavier than we had intended. But that weight turned out to be just right for allowing Handibots to do many types of cutting while being held in place only by their own weight – a bit of a happy accident.

    In our conceptualization of the challenge, the constraining factor on X-axis size is the degree to which racking of the upper part of the tool increases at greater widths due to the leverage on the offset drive of the lower Y axis. Putting drive screws on both sides would solve this problem and support an increased width, but at the cost of complexity and lost space to the additional drive.

    Increasing the length of the Y-axis is more mechanically straightforward. The drive screw and rails simply need to be longer, but housing the longer screw can get awkward and ugly — and the tool gets bigger.

    We were recently contacted by a Handibot enthusiast, John Carpenter (Carroll County Schools, Hillsville, VA), to do a longer version of Handibot that would be specifically oriented to cutting 2×12’s for construction — part of a new program he is developing. Here are a couple images of the first version, which tests an alternate position for the drive screw and has an aluminum base. This tool works well, but as you can see, it is large.

    Prototype of custom length Handibot

    Prototype of custom length Handibot

    We’re happy for any of your thoughts on size. We’ll need to make a final decision about the work area and footprint of Handibot v2.0 very soon.

    4. Rotary Indexer Preview

    Here are a couple of images of the final version of the Rotary Indexer for Handibot that Brian Owen has been hard at work on. Brian is still on target to have it available by the end of the month and it’s become a very interesting project that he’ll be reporting about.

    Handibot Indexer with work platform in machining position (left); pulled out (right).

    Handibot Indexer with work platform in machining position (left); pulled out (right).

    We’ll be packaging it up in 3 parts: 1) the work bay and sliding work platform [the mechanical indexer mounts in the bay, but the bay can also be used for mounting, clamping, and working above other types of projects]; 2) the indexer including head stock, motor, chuck, and tail stock [these components are identical to those of the Rotary Indexer that we sell for the ShopBot Desktop]; 3) the additional motor-driver and cabling that you will add to your Handibot to power the indexer [we package this separately because one will use the same motor-driver for other accessories such as the “Crawler” and you only need to purchase it once].

    Brian trimming out indexer parts.

    Brian trimming out indexer parts.


    One Response to Development Team Report / February 2015

    1. February 27, 2015 at 11:08 am

      (A a devil’s advocate on the build space question…) There is an argument to be made for _not_ increasing the cutting space. I’m fully willing to admit that it may not be a good argument, but I think it’s worth considering.

      In software development, there’s the concept of MVP, Minimal Viable Product. The idea is to make an effort to determine the smallest thing to build that will meet needs. For the Handibot, the question would be framed as _not_ what’s the largest build volume that it can be made to support, but rather what is the smallest build volume that will meet the intended uses.

      Granted, more volume generally equates to more potential. But, the Handibot is an interesting platform in that it is intended to substitute portability/tiling for build volume. This would argue for, in terms of prioritization, investments in enhancing the tiling accuracy/precision over creeping build volume.

      Of course, I crave build volume just as much as anyone, but as a platform for the future of portable, intelligent tools, it’s an interesting discussion to balance the relative merits of the two approaches; Max buildspace vs. Min viability.

    Leave a Reply

    Your email address will not be published. Required fields are marked *