Fwd: Raspberry Pi B+ HAT for FPD, EMC01 stuff

[Neil Jansen]

A week or back, the Raspberry Pi foundation came out with an updated Raspberrry Pi called the Model B+.  Same CPU specs, but the connector placement, mounting hole location(s), and modularity is much better now.  I originally wanted to tuck the RasPi away under the LCD but the connectors wouldn't let me.  Now that they've released the B+, we can tuck it away and have a clean machine without a lot of wires sticking out everywhere.  We also have the opportunity to integrate a few boards together here and save some money off the final BOM cost.

Offical blog post on the Model B+: http://www.raspberrypi.org/introducing-raspberry-pi-model-b-plus/

Here's the Raspberry Model B+, that I've imported into Cubify Design (notice the nice 4-hole rectangular mounting system, and lined-up connectors, with no giant video or audio jacks sticking out of the top side)

I mentioned modularity above.  The Raspberry Pi Foundation also made an official specification for what they're calling a "HAT", which is the same idea behind an Arduino shield, or Beaglebone cape. 
People have been making accessories for them before, but they weren't standardized.

Here's the official blog post on the Raspberry Pi HATs: http://www.raspberrypi.org/introducing-raspberry-pi-hats/

And here's the Github repo where they're keeping the official specification to make a compatible HAT: https://github.com/raspberrypi/hats (you can find schematics and mechanical dimensions here)

Also, someone has made an EAGLE library for the HAT, although I've not verified it: http://www.raspberrypi.org/forums/viewtopic.php?f=100&t=82618&sid=fce0d285d3d56f8a7bbd4c21a75c4bbe

I modeled the HAT dimensions and added some connectors.  You can see that I've tried to integrate the HDMI-to-FFC pass-through for the RasPi camera onto this board.  It makes a lot of sense do it that way.  I've also added JST connectors for the front panel rotary encoder and the pushbutton switch. 

​

We can also wire the LCD directly up to this HAT, like this:

​

This whole module would sit in the FirePick Delta frame like this:

Obviously I've not added the pins for the LCD to HAT yet, and the FFC connector would need to move up a bit.  And the pushbutton switch and rotary encoder isn't shown.  But the idea is that this strategy would make a nice clean front panel, where I could cover the LCD sides up with 3D printed side panels, like I have now:

​

​

​Basically, the LCD pins between the Raspberry Pi are the same as what we had already, which is:
https://learn.adafruit.com/drive-a-16x2-lcd-directly-with-a-raspberry-pi/wiring (noting that I think they made that tutorial for the Rev 01, and I think some pins got changed).

The buttons and encoders are connected to JST's so the actual buttons will be panel-mount with wire-and-connector pigtails, so people can use whatever they want.  This is better than the first iteration that tried to make them PCB-mount which makes it a huge board in EAGLE, which runs into licensing issues.

The HDMI pass-through is the same as what we have now (using Christian's pinout, not mine that I did for the prototype but never checked in).  We actually have a neat possibility of using MULTIPLE cameras with the Raspberry Pi Model B / B+, which is a surprise to me, but apparently it's been done: https://www.indiegogo.com/projects/ivport-raspberry-pi-camera-module-multiplexer  I think they're just switching the power on and off for the various cameras.  But that would allow us to add a second HDMI for an up-looking camera that could come in handy.  We don't need the multiple cameras in the first rev of this board, I'll likely prototype up something at home to make sure I can get a usable circuit before we add it.. but it's cool that we can add it when the time is right, without having to use a Compute Module.

I think we can fit a tiny piezo speaker and small opamp on the board, that would go into the Pi's audio jack with a right-angle connector.

The HAT specification includes an EEPROM, and circuitry for backfeeding +5V power into it.  We need to add that to our HAT, and add a connector to get +5V, or +12V (and regulate down to +5V), into the board.

There are official rules to what criteria you have to meet before you can call your board a HAT. If we don't meet that criteria, we can use another acronym, like FEDORA, for "Firepick Electronics Display something-something Assembly"... Because we don't have enough crazy acronyms... lol.

I've not made a schematic for it yet, but I might try to do that on the 5 hour plane ride that I have tomorrow :)  I can email it over during the 2-hour layover.

Hope all that made sense.  It's a bit different from how I originally envisioned it, but I think now that the Model B+ and the HAT specification is out there, it makes sense to do it this way.


I've also spent a bit of time modeling up the EMC01 board and the modular tools that go into it:

The little boards sticking up out of the acrylic (which I need to add slots to), are the modular PCB's that contain the stepper drivers and whatnot for each modular tool.  I'm still working on diagrams and stuff for showing how the modular PCB goes to a little box that hangs on the back of the machine for the extruder or vacuum pump or whatever, and then a series of wires and tubes that go down to the actual tool that sits in the end effector.  James is working on an auto-tool-change mount that will allow the machine to change tools on its own.  I'll be updating the model frequently when I get back from Seattle, but you can see the files in github and view them if you download the 30-day trial of Cubify Design for Windows.

​

Let me know what you guys think.  I've asked Dayton and he feels confident that he can do the routing.  I'd like to get some feedback before officially starting on it though.

Thanks,

Neil

​

[Josh Pritt]

I was actually wondering if you'd seen the B+ and if it would be better for the fire pick.  Awesome how well it fits. I say make it so!

Sent from my iPad mini

On Aug 3, 2014, at 3:47 PM, Neil Jansen <njan...@gmail.com> wrote:

A week or back, the Raspberry Pi foundation came out with an updated Raspberrry Pi called the Model B+.  Same CPU specs, but the connector placement, mounting hole location(s), and modularity is much better now.  I originally wanted to tuck the RasPi away under the LCD but the connectors wouldn't let me.  Now that they've released the B+, we can tuck it away and have a clean machine without a lot of wires sticking out everywhere.  We also have the opportunity to integrate a few boards together here and save some money off the final BOM cost.

Offical blog post on the Model B+: http://www.raspberrypi.org/introducing-raspberry-pi-model-b-plus/

Here's the Raspberry Model B+, that I've imported into Cubify Design (notice the nice 4-hole rectangular mounting system, and lined-up connectors, with no giant video or audio jacks sticking out of the top side)

<Raspi_bplus.png>

I mentioned modularity above.  The Raspberry Pi Foundation also made an official specification for what they're calling a "HAT", which is the same idea behind an Arduino shield, or Beaglebone cape. 
People have been making accessories for them before, but they weren't standardized.

Here's the official blog post on the Raspberry Pi HATs: http://www.raspberrypi.org/introducing-raspberry-pi-hats/

And here's the Github repo where they're keeping the official specification to make a compatible HAT: https://github.com/raspberrypi/hats (you can find schematics and mechanical dimensions here)

Also, someone has made an EAGLE library for the HAT, although I've not verified it: http://www.raspberrypi.org/forums/viewtopic.php?f=100&t=82618&sid=fce0d285d3d56f8a7bbd4c21a75c4bbe

I modeled the HAT dimensions and added some connectors.  You can see that I've tried to integrate the HDMI-to-FFC pass-through for the RasPi camera onto this board.  It makes a lot of sense do it that way.  I've also added JST connectors for the front panel rotary encoder and the pushbutton switch. 

​

<Raspi_bplus_withhat.png>

We can also wire the LCD directly up to this HAT, like this:

​

<Raspi_bplus_withhat_withlcd.png>

This whole module would sit in the FirePick Delta frame like this:

<front2.png>

<uplcd.png>

<sidelcd.png>

Obviously I've not added the pins for the LCD to HAT yet, and the FFC connector would need to move up a bit.  And the pushbutton switch and rotary encoder isn't shown.  But the idea is that this strategy would make a nice clean front panel, where I could cover the LCD sides up with 3D printed side panels, like I have now:

<2014-07-14>

​

​

​Basically, the LCD pins between the Raspberry Pi are the same as what we had already, which is:
https://learn.adafruit.com/drive-a-16x2-lcd-directly-with-a-raspberry-pi/wiring (noting that I think they made that tutorial for the Rev 01, and I think some pins got changed).

The buttons and encoders are connected to JST's so the actual buttons will be panel-mount with wire-and-connector pigtails, so people can use whatever they want.  This is better than the first iteration that tried to make them PCB-mount which makes it a huge board in EAGLE, which runs into licensing issues.

The HDMI pass-through is the same as what we have now (using Christian's pinout, not mine that I did for the prototype but never checked in).  We actually have a neat possibility of using MULTIPLE cameras with the Raspberry Pi Model B / B+, which is a surprise to me, but apparently it's been done: https://www.indiegogo.com/projects/ivport-raspberry-pi-camera-module-multiplexer  I think they're just switching the power on and off for the various cameras.  But that would allow us to add a second HDMI for an up-looking camera that could come in handy.  We don't need the multiple cameras in the first rev of this board, I'll likely prototype up something at home to make sure I can get a usable circuit before we add it.. but it's cool that we can add it when the time is right, without having to use a Compute Module.

I think we can fit a tiny piezo speaker and small opamp on the board, that would go into the Pi's audio jack with a right-angle connector.

The HAT specification includes an EEPROM, and circuitry for backfeeding +5V power into it.  We need to add that to our HAT, and add a connector to get +5V, or +12V (and regulate down to +5V), into the board.

There are official rules to what criteria you have to meet before you can call your board a HAT. If we don't meet that criteria, we can use another acronym, like FEDORA, for "Firepick Electronics Display something-something Assembly"... Because we don't have enough crazy acronyms... lol.

I've not made a schematic for it yet, but I might try to do that on the 5 hour plane ride that I have tomorrow :)  I can email it over during the 2-hour layover.

Hope all that made sense.  It's a bit different from how I originally envisioned it, but I think now that the Model B+ and the HAT specification is out there, it makes sense to do it this way.


I've also spent a bit of time modeling up the EMC01 board and the modular tools that go into it:

<top.png>

The little boards sticking up out of the acrylic (which I need to add slots to), are the modular PCB's that contain the stepper drivers and whatnot for each modular tool.  I'm still working on diagrams and stuff for showing how the modular PCB goes to a little box that hangs on the back of the machine for the extruder or vacuum pump or whatever, and then a series of wires and tubes that go down to the actual tool that sits in the end effector.  James is working on an auto-tool-change mount that will allow the machine to change tools on its own.  I'll be updating the model frequently when I get back from Seattle, but you can see the files in github and view them if you download the 30-day trial of Cubify Design for Windows.

​

Let me know what you guys think.  I've asked Dayton and he feels confident that he can do the routing.  I'd like to get some feedback before officially starting on it though.

Thanks,

Neil

​

--
You received this message because you are subscribed to the Google Groups "FirePick" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

[Karl]

A week or back, the Raspberry Pi foundation came out with an updated Raspberrry Pi called the Model B+. 

Neil, in all seriousness, my hat's off to you. :)

Amazing job on the design specs--these pictures really facilitate assembly. Guess I'll be ordering a B+ soon, although I'll still be using my two RPi's for prototyping. Thanks for splitting out the LCD board--the software folks don't need an LCD since we use software tools to determine server addresses. However, we  do need indicator lights on at least one of the custom boards. I thought about using RPi's own LEDs, but it didn't feel right to usurp their current semantics. Any chance you hardware guys could park a few indicator LEDs on your board(s) for us?

[Thomas A. Kilbride]

I think making the "hat" is a great idea.

I can see this getting FPD some great publicity if we are featured on RPi's webiste. We would the first ones to market a hat. Additionally this could help make the design future-proof for later revisions of the RPi if they choose to keep the same pin-out for the hats, this could add some backward compatibility; however, this is speculative.


Thomas.

[Joshua Pritt]

I also like the idea of being one of the first projects to market a raspberry pi hat.

[Assaf Inbal]

Does this mean you're dropping the possibility of using the RPi compute module?

Won't that give you greater flexibility with arranging ports, smaller footpring and perhaps combine multiple boards together?

[Neil Jansen]

We'd like to eventually support the compute module, but it requires a pretty complicated carrier board design with at least a 4-layer board with lots of phase-matched, controlled impedance traces.  So we'll likely put this off until at least early 2015, which gives us more time to concentrate on other parts of the design.

[Assaf Inbal]

Ah, makes sense. I was under the impression that the compute module was supposed to be easy to integrate.

Please excuse my ignorant outburst :)

Go team!

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+unsubscribe@googlegroups.com.

[Bryan Mayland]

I do love those renders. So much easier to understand than "and then the HAT goes on the Pi, and then the LCD on top of that!". I also had the same problem with the compute module in my project. Sure it is small but I don't have the technology at my disposal to solder that socket or design a board without messing it up.

Just to check, in your rendering isn't the LCD upside down? All the LCDs I've seen (with the exception of select NewHaven Display modules) have had the 16 pins along the top instead of the bottom.

[Neil Jansen]

You're probably right, I was throwing the model together pretty quickly before leaving for Seattle, and wasn't taking my time :)  well definitely want the LCD right-side-up, so ill double-check that when I get back next Monday.  We want to use the cheapest 16x2 LCD that money can buy, which are usually < $10 from US distributors, and < $2 from Chinese manufacturers directly.  They use the "standard" LCD footprint which I believe have the pins on top like you mentioned.

The "pro" version of this machine, however, will likely have a 40x2 LCD like the one in the picture above, as it looks cooler, and is still < $15 from Chinese manufactures, if purchased directly.

On Tuesday, August 5, 2014, Bryan Mayland <cap...@gmail.com> wrote:

I do love those renders. So much easier to understand than "and then the HAT goes on the Pi, and then the LCD on top of that!". I also had the same problem with the compute module in my project. Sure it is small but I don't have the technology at my disposal to solder that socket or design a board without messing it up.

Just to check, in your rendering isn't the LCD upside down? All the LCDs I've seen (with the exception of select NewHaven Display modules) have had the 16 pins along the top instead of the bottom.

--

You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

[Neil Jansen]

I've created a schematic for the Raspberry Pi B+ "HAT", and added the following circuits:

- Raspberry Pi B+ 40-pin connector with coupling capacitors

- 16x2 LCD interface (currently supports single-backlight LED versions, but may update this to support RGB version with three cathodes)

- Button and encoder interface via JST connectors (Need to eventually make a wiring diagram for the switches and encoders, plus a BOM for them)

- Raspberry Pi CSI 15-pin camera connector interface to HDMI (pass-through for remote-mounting camera on end-effector)

- Piezo buzzer circuit (uses GPIO pin 18 rather than the audio, which saves us a connector and precious board real-estate.  GPIO18 has hardware PWM).

- Raspberry Pi Model B+ EEPROM circuit, for auto-detecting HAT.  This is a requirement that must be in place to be called a "HAT".  We may be able to DNP the parts for a cheaper version... I'll play around and find out.

- Raspberry Pi Model B+ 5-volt backfeed protection circuit.  Required for HATs that provide +5V via GPIO pins 2 & 4.

- A connector that has +12V and GND.  This connects directly to the 12V power supply, and can do so

- No TTL serial to the EMC01 like I originally wanted.  Seems easiest just to use a standard USB micro or mini, connected from the Pi to the EMC01 (meaning we'll add a USB mini/micro and FT232 to the EMC01). 
- +12V to +5V switching power supply, to give the Pi a nice clean +5V (lots of brownouts by using questionable power supplies can be prevented here).  This actually frees up the EMC01 5V supply that originally powered the Pi, which should keep the EMC01 board cooler (we should, according to my calculations, be able to get rid of the LM2576 that was on the EMC01 now, and either use a tiny linear regulator or the USB power provided by the Pi).  I'd like to eventually go with a cheaper / better switching power supply than the LM2576, but it'll do for the first beta test run.  The board is super small and easy to rev.

It's checked into github, it's in EAGLE format since I'm better with that than KiCad.  I'm hoping someone can help me do the routing now that I've got the schematic in decent order.  Any takers? :)



Thanks,

Neil

[Neil Jansen]

Tried to upload the schematic image, here goes again:

​

​

[Daniel Dumitru]

HEllo ,

I volunteer to route it of you would accept to work in Kicad. (I have never managed to understand Eagle)

By the way, did you know that Kicad has push and spring routing ?

BR,

Daniel

[Neil Jansen]

Daniel,

It would be easier at this point to keep the design in EAGLE rather than to redraw it in Kicad, as I've spent a lot of time getting the footprints right.  

However, if you have experience taking an EAGLE drawing and converting the PCB and footprints to Kicad, using scripts or ULP's, then let me know :)

Thanks,

Neil

[John Kha]

I am trying to get the development version of kicad working so i can work with eagle files. I hope I can, so far it has been a royal pita. I don't know how well the Eagle inter connectivity works, but I am gonna give it a shot, and I will let you know if its worth installing the latest developement version or not. 

Here is a video expaining the push shove functionality mentioned above. https://www.youtube.com/watch?v=CCG4daPvuVI

--John

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+unsubscribe@googlegroups.com.

To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

[John Kha]

Neil,

I have been re-drawing your schematic in KiCAD. I also downloaded eagle, and i think there may be a ulp or whatever to translate this, but there were some other things i wanted to change, so i am just redoing it. I will send a pull request when I am done with that and the layout, but the I had a question first: Your schematic doesn't really say where PANEL_ENC_SW, etc connect to, did you want those attached to the GPIO on the B+? If so, did you have any pins in mind, or should I just attach them where i want?

After I finish the basic board, I am probably going to work on at least one, possibly two different more advanced boards. I hope to support an on-board or extended io board with a small joystick, and will fully implement the RGB LED backlit character displays and possibly have an interface for Adafruit's TFT with the SPI interface. I have a 2.8 inch version that also can work with data, but would also try and work in support for their smaller displays. I might make it to where that display would be in a completely separate assembly possibly in a completely separate assembly. If it gets too out of control I would split the one with the graphic display off to a second advanced board. What I am really getting at here is that I would like to reserve a couple of part numbers. ERPIHAT02 and ERPIHAT03, maybe. It would also be helpful for me to get some STLs or renderings of where and you plan to mount this on the chassis, even if it just a rough idea.

[John Kha]

Neil,

I think I will be able to use your footprints in my layout in kicad, once i finish the schematic. The microwave tools in Kicad really make it worth moving things over there. I will be sure to save the footprints in a kicad library and pull request that, too.

--John

On Tuesday, August 12, 2014 1:05:28 PM UTC-5, Neil Jansen wrote:

[John Kha]

Is it critical that all of the traces with the camera differential signals match? or just the two traces in a pair?

I have attached what I have done so far. As is, the individual signal pairs match each other, but but each pair is a different length.

Let me know if you don't like where this has gone so far. I will probably send a pull request when I get back from dinner.

--John

[Neil Jansen]

Yes, it's critical that all the differential signals are routed together, not only through the pcb, but also across the HDMI cable.  We have another board on the other end of that, so it's critical that they both match.  The camera will not work if they're not wired out identically on both ends.  I had originally chosen one pin wiring strategy, and then Christian came up with another, that is easier to route, but still has the differential pairs routed together.  The schematic for that is actually in the github repo, on a different board, here: https://github.com/firepick-delta/firepick-delta/tree/dev/electronics/eservoaccel01  I've got a note in the schematic to go back up and update the nets to reflect Christian's wiring strategy.  It might be after the 20th until I can have a chance to do that, as I'm trying to meet other milestones and deadlines.

Also, now that I've gotten a bit of time to model the HAT files out better in Cubify, I've updated the dimensions a bit for the connectors.  I'll have that checked in soon hopefully. It shouldn't cause any re-routing or anything like that.  I'm going to draw up a Cubify 2D print drawing with dimensions, that should serve as a reference for all of the HATs we end up making, including the positions of connectors we're adding to it and other useful stuff.

Isn't working on a moving target fun :)

[John Kha]

I actually captured the pin out from ehdmifpc01 and put it into my routing scheme. I just wasn't sure if the lengths had to be the same across the pairs. Pretty easy to do in kicad, and i saw what christian did with the microwave tools, which I could do too. I just wasn't sure if it was necessary to match across all the pairs or just between the two wires in a pair. I did move the power connector from between the two 4 pin connectors because routing that fatter trace around it was a bit unwieldy. Not being able to see what you are doing in Cubify makes some things a bit challenging. 

--John

[John Kha]

Neil,
No worries, I may withdraw my pull-request and change that before then
if i get around to it. I did notice, though, that the ehdmifpc01
part's base directory is in KiCad. Are we going to put all of the base
directories in Eagle and standardize around that? It is relatively
easy to add eagle boards to KiCad, and there is a way to save Eagle
Schematics to KiCad with the ulp located here:
http://www.circuitbee.com/help/eagleimport, though I haven't tried it
out, and it looks like it was originally written for Eagle 5.8. For
those reasons, I would recommend standardizing around KiCad instead. I
can see why you would want to go with Eagle, since it seems like more
people know how to use it, but since KiCad is open-source, it is
probably more accessible to people, and once you learn it you don't
have to start paying for it to scale up to larger projects.

On a completely different note, is there a high-level inter-board
block diagram or something of the current or final setup, including
any laptops/json-connected-computing-devices that are involved? I
can't really figure out how you have every thing pieced together from
looking at published pictures and what I've found so far. Also, is the
presentation you used for the HaD video available somewhere outside of
youtube? More information on the systems level integration would be
nice.

The other thing i can't figure out is how you use the auto-tool
changer with tools that involve something coming from the top (which
is pretty much everything, with wires, and filament and tubes for
paste extrusion, etc. I am sure all of that would be obvious, if I had
Cubify, which I may still get eventually (I might try to get it going
with wine, otherwise, I'll see if i can get my Windows VM ticking
again.)

Anyways, appreciate all the work you are putting into this.

John


--John

On Sun, Aug 17, 2014 at 7:54 PM, Neil Jansen <njan...@gmail.com> wrote:
> Got it, my apologies. I wouldn't say that the trace lengths are critical to
> get right. However I'd like them to be, just to be on the safe side. My
> first version, which isn't checked into github, and had been used
> successfully on FPD #1, didn't have matched lengths or controlled
> impedances, and it's worked fine. However if we have the tools to make it
> right I'd rather take the time and do it rather than taking a chance.
> Ideally, we want all of the differential pairs / lanes to be exactly the
> same length. I2C and power obviously aren't critical.
>
> Thanks again,
>
> Neil

--
John C. Kha

[Neil Jansen]

I did notice, though, that the ehdmifpc01 part's base directory is in KiCad. Are we going to put all of the base directories in Eagle and standardize around that?

 I'm not sure I follow.  For the EAGLE files in github, there's not really any base directories used, it's completely outside of EAGLE (kind of a PITA but EAGLE is a dinosaur, I don't expect them to handle concepts like revision control awareness very well).  I've never used Kicad so I can't really say much there.  Either way, i'll defer to other kicad experts like Christian (not sure he's following the google groups closely, I may forward this thread to him).  Basically we want to keep everything FPD related in the Git repo, and any non-FPD related stuff out of it.

It is relatively easy to add eagle boards to KiCad, and there is a way to save Eagle Schematics to KiCad with the ulp located here: http://www.circuitbee.com/help/eagleimport, though I haven't tried it out, and it looks like it was originally written for Eagle 5.8. For those reasons, I would recommend standardizing around KiCad instead. I can see why you would want to go with Eagle, since it seems like more people know how to use it, but since KiCad is open-source, it is probably more accessible to people, and once you learn it you don't have to start paying for it to scale up to larger projects.

The only reason that I use EAGLE is because I've used it for 15 years, and have never used Kicad.  Obviously EAGLE has its problems (so does Kicad however).  It's just what I know and it's the quickest way for me to do a braindump of whatever ideas I have.  I wanted some really unique stuff in the EMC01 and ERPIHAT01 that would have been hard to describe in written technical prose, so I captured it all with EAGLE.  Rather than having Kicad as the standard, I'd rather have both Eagle and Kicad files available.  Once I route the EAGLE board, and once your pull request has been integrated, we should be able to do that no problem for ERPIHAT01.  Obviously the EMC01 board is EAGLE-only at this point, we'd obviously need someone to volunteer to get it in Kicad or we just accept that it's EAGLE only.  Christian Lerche was helping us with Kicad, he's a real guru with it, but he's moving into a new house at the moment.  Our other two pcb/layout guys, Thomas and Dayton, use mostly Altium and EAGLE, respectively.  

 

On a completely different note, is there a high-level inter-board block diagram or something of the current or final setup, including any laptops/json-connected-computing-devices that are involved?

Yes.  I'm drawing that right now.  it's coming along quite nicely.  I'll have it posted by the 20th at the latest (that's our hard deadline for the Hackaday contest).  It 

 

I can't really figure out how you have every thing pieced together from looking at published pictures and what I've found so far. Also, is the presentation you used for the HaD video available somewhere outside of youtube? More information on the systems level integration would be nice.

I should have info ready to answer all of those questions and more, by the 20th.  Those things basically have my undivided attention right now, and I'm working frantically to get it all done by then.

 

The other thing i can't figure out is how you use the auto-tool changer with tools that involve something coming from the top (which is pretty much everything, with wires, and filament and tubes for paste extrusion, etc. I am sure all of that would be obvious, if I had Cubify, which I may still get eventually (I might try to get it going with wine, otherwise, I'll see if i can get my Windows VM ticking again.)

It works great right now as a manual tool change system (twist and lift the tool out with your hand).  My friend James is working making the auto tool change brackets.  We'll be prototyping those and writing machine code to perform the tool change operations, in the coming weeks/months.  The diagrams that I'm working on will hopefully explain it a bit better than what's out there right now.

 

Anyways, appreciate all the work you are putting into this.

Thank you for stepping up and helping the project.That's the first real pull request we've gotten, besides one to fix a typo on a markdown page :-/

 

[Christian Lerche]

I'm following, and I'll have my home-lab set up in a week or two, so I'll be able to pitch in where I can.