Fwd: [DIYbio] Re: Cubespawn group is working on parallel concepts now

[John Griessen]

Date: Thu, 21 Feb 2013 19:17:33 -0800 (PST)
From: Dietrich Dehlinger

Realistically, we're looking to use some of the same technologies. I don't think the assembly line philosphy/geometry is right for
something like squidbot (which is way more recursive), but a lot of the same issues are at play.

On 02/21/2013 08:52 AM, John Griessen wrote:> Patrick D'H wrote:
> "- 180 x 90 cm sounds very large - that's 6 x 3 feet, and would take up an entire lab bench! Could you get away with 3 x 3 ft,
> until you have most of the kinks worked out? Expanding the length of the gantry afterwards should be reasonably straightforward.
>
> - Were you guys planning to design a separate PCR machine as well? "
>
> There is another project considering what control hardware and software to use for modular
> open manufacturing robots right now that you al should consider cross pollination with.
> It's called Cubespawn. They're discussing using ROS, ARM platforms like R-Pi, SmoothieBoard
> and The basic idea is starting off with modules that are made from T slotted extrusion
> with overall dimensions of 300mm increments.

cubespawn is in early conceptual stages, and will allow recursive flow of material via aisles between lines
with mover-bots in the aisles. The aisle mover bots are probably going to be lower tolerance movement
than a gantry-bot-hand, but cube modules will use vision to grip, align and precisely move objects delivered to them.
Cubespawn style systems will probably be able to do bio lab work also, just slightly different handling steps,
and more reconfigurable since modularity is core to the cubespawn concept.

There's not much stopping sharing some discussion about code and controller platforms to use and vision systems,
even if you think it is too different a goal.

[John Griessen]

The post that started this is inline below:

-------- Original Message --------
Subject: Squidbot
Date: Thu, 21 Feb 2013 05:25:01 -0800 (PST)
From: Dietrich Dehlinger

To: biocurious-ro...@googlegroups.com



We've started up the SquidBot Project. Go to https://groups.google.com/forum/?fromgroups#!forum/squidbot for the discussion on the
planning and implementation of that system.

And one of the archived posts has the attached notes to this email from their concept meeting that can be opened
with libreoffice

[CubeSpawn]

Interesting, are talking about the DARPA Squid-bot? or something else...

CubeSpawn is (initially) pretty straight FMS with maybe even an slightly older design model - but nothing stands in the way of taking it in different directions:

so far:

One discussed concept was using 3d printing for reaction chambers to make a private Pharma factory,

a food processing line,

a self sterilizing bio-printer farm with sample management and more

wooden (kitchen) cabinet making line

SMT pick and place line

a promotional product markup machine

A composite garment printer

a composite injection molding and vacuum forming line

a chef's prep line

straight machining line - lathe-mill-precision grinder

some bizarre combo of above features is also certainly possible

 

On Thursday, February 21, 2013 9:37:53 PM UTC-6, John Griessen wrote:

Date:         Thu, 21 Feb 2013 19:17:33 -0800 (PST)
From:         Dietrich Dehlinger

Realistically, we're looking to use some of the same technologies. I don't think the assembly line philosphy/geometry is right f?or

[John Griessen]

On 02/21/2013 10:06 PM, CubeSpawn wrote:
> talking about the DARPA Squid-bot? or something else...

I heard no mention of DARPA yet. It's open collaboration, so probably not.

[CubeSpawn]

Yeah, just read through the groups posts, seems very specific about electrical details and such,

 it will bear watching and perhaps some horse trading will occur :-)

[John Griessen]

On 02/22/2013 02:16 AM, Patrik D'haeseleer wrote:
> Wouldn't hurt to stick to some of the same design standards though. Unless they're conflicting with existing standards in lab
> robots, of course.
>
> Patrik

>
> On Thu, Feb 21, 2013 at 7:17 PM, Dietrich Dehlinger <ddeh...@gmail.com <mailto:ddeh...@gmail.com>> wrote:
>
> Realistically, we're looking to use some of the same technologies. I don't think the assembly line philosphy/geometry is right

> for something like squidbot (which is way more recursive), but a lot of the same issues are at play.

So far, the design standards we are looking at are different module wise, and module size-wise -- we are
making an overall supervising system for small steps, or micro-scale steps in operations on things
that are human scale, and in the past have been moved around by humans to be processed. The 300mm cubes
are a first cut, and later some larger cubes will be engineered, and something like squidbot
could be used as one module in a cubespawn system, which might fill a room.

What could be in common is control systems and software, such as using ARM microcontrollers with ethernet
to take advantage of the large selection of peripherals available on these micros, and the strong
evolution of ethernet, which is low cost and high speed. We don't want to be stalled by limits of
hardware when ARM M3 micros with ethernet cost $6 from TI and ST. Each module will be able to use anything for side purposes,
but ethernet is one required standard we are thinking of now. Another control system choice we are looking
at is Smoothie, which runs without any heavier OS, is a real time OS, but minimal, and works on low power consumption
inexpensive, micros with memory amounts like 128Kbytes. Modules can have multiple micros, but one will have a serial
ethernet connection for messages to and from ROS running on platforms like R-Pi so they can have a GUI for setting up
function of a processing group of modules. ROS sends messages that are easy for humans to debug and understand and
sequence into programs. With ethernet's large data capacity, debugging modules can be aided by including
info like image frames from vision systems to help figure out "what went wrong", and storing them on the ROS
node where there is room to keep such data -- data the module nodes use for decisions and discard usually.

[James Jones]

One other speculation for the 300mm cubes, one of the most interesting elements (to me) of machines this small is a teleoperations interface for two main reasons: directly manipulating very small things and; training a motion control to automate the manipulation of very small things....

If this is self extending via the machine shop modules of the 600mm cubes and the control architecture, then "tunnelling" via generations of smaller and smaller "cubes" (might be rhomboids at these scales... ? who knows...) to molecular level manipulation is an implementations problem, not a fantasy...

No it won't be by next week, or even next year, but it is certainly possible. 

and if your control architecture is designed to facilitate automation at any scale, then broadly parallel operations are an intrinsic property and at small scales...

this could someday mean:

 "Earl Grey, hot" isn't just Hollywood anymore

--
You received this message because you are subscribed to the Google Groups "Cube Spawn" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cube-spawn+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Griessen]

On 02/21/2013 10:23 PM, CubeSpawn wrote:
> perhaps some horse trading will occur :-)

They have barely acknowledged what I sent and aren't talking about any distance collaboration,
just local face to face meetups and rapid progress with Arduino limitations.

Their email list was called squidbot, now called biocurious-l...@googlegroups.com

Oh well, it seems only SF biocurious related.

Back to occasional long range planning.

[James Jones]

well this weekend was more open than usual, aside from increased gardening prep tasks, so I got my little Chinese netbook (WonderMedia 8505) converted to debian (it origionally ran WinCE (yuck!!)

And, this solved the problem I had with my old card readers not seeing 4GB SHDC cards, this led to getting the Raspbian card prepped for the R-Pi, getting it networked and VNC running on it, I then switched networks and everything netbook related broke ;-) so I'm rebuilding the netbook install (much quicker this time) and I'll build the BeagleBone debian card image and reinstall ROS groovy on-board 

I also connected to an Arduino UNO, a JeeNode, and the Mega on the Ultimaker board and had no trouble communicating with them - so getting ROS Serial running will be on top of the good foundation of known function...

I'm feeling WILDLY optimistic, made a ton of progress today! 

 

On Sun, Feb 24, 2013 at 6:21 PM, John Griessen <jo...@industromatic.com> wrote:

On 02/21/2013 10:23 PM, CubeSpawn wrote:

perhaps some horse trading will occur :-)

They have barely acknowledged what I sent and aren't talking about any distance collaboration,
just local face to face meetups and rapid progress with Arduino limitations.

Their email list was called squidbot, now called biocurious-labautomation@googlegroups.com

Oh well, it seems only SF biocurious related.

Back to occasional long range planning.

[John Griessen]

On 02/24/2013 08:56 PM, James Jones wrote:
> I also connected to an Arduino UNO, a JeeNode, and the Mega on the Ultimaker board and had no trouble communicating with them - so
> getting ROS Serial running will be on top of the good foundation of known function...
>

That's great James. Lots of progress.

ROS seems like it would be good controlling a line or group of cube machines.
Does ROSserial work only with a UART serial port, or can it work with ethernet
somehow also? (I have not read up on ROS enough to know yet...)

[James Jones]

It'll work over a number of different communication channels including serial and tcp/ip although it has some implementation problem in non-8 bit architectures handling memory - but a (non-approved) work-around exists using protocol buffers, which still leaves some extra complexity in the implementer's hands, but for the near term, I don't see this affecting anything being done right now....

[John Griessen]

On 02/25/2013 06:28 PM, James Jones wrote:
> I don't see this affecting anything being done right now....

What's being done? I'm just pondering it,
(and doing plumbing and electrical construction work...).

[John Griessen]

Uh... Sorry for that remark. I was getting way ahead of myself disapproving like that.

Today was weird with the 50mph winds distracting while trying to get a tankless water heater plumbed.

Your testing out lots of kinds of comm between
modules is valuable work on figuring out what softwares/hardware-platforms are
real-not-vapor.

Thanks James.

[James Jones]

Believe me, John, I sometimes ask myself the same question.

It IS frustratingly slow progress, most of the time I always seem to lack one of the three critical elements:

Time,

Money,

Motivation

Getting all three to synchronize, is the perennial problem.

I appreciate your sometimes pointed questions, they usually stimulate verification and research.

Also, the mechanical stuff is harder to accomplish, I see why so many folks stick to software, its time consuming, but you never bore an oversize hole in an expensive piece of software, aluminum, on the other hand... ;-)

[John Griessen]

On 02/26/2013 08:18 AM, James Jones wrote:
> It IS frustratingly slow progress, most of the time I always seem to lack one of the three critical elements:
> Time,
> Money,
> Motivation

The biocurious lab automation group seems to be keeping motivation up by setting low and easy goals.

Probably because we're experienced engineers we set higher goals for ourselves. It might be good to
just use an Arduino compatible to start and worry with cost reduction and performance increase later.

But smoothie seems just the thing for a mill, and it's not arduino-easy-button, so there we are.
I'll try to find some time to test out smoothie on my STM32 discovery board in March.

[James Jones]

I agree with both points regarding arduino, so grbl on arduino seems like a reasonable compromise, and it solves a whole nest of minor, related challenges in one effort i.e.:

Serial comms,

Serial comms with arduino from ROS

Serial comms with grbl from ROS

Feeding commands to eith or both - maybe knowing the difference by detection

Reciving ack/nack level status, 

Understanding ROSSerial stack comms,

 implementing same in the ROSSerial framework,

 etc, etc, blah on down the line 'till something very cool is running,

My mind, being vastly more capable of imagining things than my skills are able to implement is running a good 10 years ahead of me on my project.....

[John Griessen]

On 02/26/2013 05:46 PM, James Jones wrote:
> grbl on arduino seems like a reasonable compromise, and it solves a whole nest of minor, related challenges in one effort i.e.:
> Serial comms,
> Serial comms with arduino from ROS
> Serial comms with grbl from ROS
> Feeding commands to eith or both - maybe knowing the difference by detection
> Reciving ack/nack level status,
> Understanding ROSSerial stack comms,
> implementing same in the ROSSerial framework,

grbl on arduino does that much? Where do I read about that?

[James Jones]

well, no.

Grbl on arduino in place of a smoothie board as one part of solving all those problems,

probably could have phrased it better, stating that I agreed with your points, and that one of the pieces (smoothie) of the larger problem (ROSonSBC-driving machine-tool-low level-logic) could be partially solved by running the grbl-on-arduino in place of smoothie for now, and the other issues come along as part of an effort to solve the general problem.

grbl is not solving any problem outside of turning G-code into motion outputs, but, I can run it TODAY, whereas a smoothie board, I would have to buy....

Clarity and brevity sometimes clash in my statements!! rendering them neither... :-)

...(short, or comprehensible)

[John Griessen]

On 02/26/2013 09:00 PM, James Jones wrote:
> grbl is not solving any problem outside of turning G-code into motion outputs, but, I can run it TODAY, whereas a smoothie board,
> I would have to buy....

Ok gotcha.

I still like smoothie. Need to try it on a $15 STM32 discovery eval board.

Buying a smoothieboard gets you lots of engineering done for connectors and such.
Smoothieboard is based on a LPC?? chip by NXP(Philips). I just like the range of options
and lower prices of ST's line of ARM chips better is why I got the STM32 discovery eval board
to try out. And because there's Dave Raphael developing for it that can teach me how it goes
at a low level, then go to Mr. Wolf for smoothie developments at a higher level abstracting away
from the particular hardware. Being a hardware guy, I always like to learn the low down
foundation of the higher abstractions I use.

[John Griessen]

On 02/26/2013 09:00 PM, James Jones wrote:
> grbl is not solving any problem outside of turning G-code into motion outputs, but, I can run it TODAY, whereas a smoothie board,
> I would have to buy....

Here's another you could buy, (from the group developing the squidbot gantry liquid handler):

http://www.reprap.org/wiki/File:RRD-RUMBA.JPG

[John Griessen]

On 03/03/2013 12:34 AM, Jonathan Cline wrote:
> This and other reasons is why industrial/automotive/lab equipment typically uses CAN bus

Have any CAN bus apps for PICs, UBW that are open?

[John Griessen]

-------- Original Message --------
Subject: [DIYbio] Re: Cubespawn group is working on parallel concepts now
Date: Sat, 2 Mar 2013 22:34:39 -0800 (PST)
From: Jonathan Cline <jnc...@gmail.com>
Reply-To: diy...@googlegroups.com
To: diy...@googlegroups.com
CC: Open Manufacturing <openmanu...@googlegroups.com>, Bryan Bishop <kan...@gmail.com>, biocurious
<biocu...@googlegroups.com>, James Jones <data.p...@gmail.com>, jcline <jcl...@ieee.org>




300 mm, because? We have 3 fingers on each hand and like to think in base 3.

If the design needs a chip-to-chip communication method more than 10 cm it should use a differential voltage physical layer
(ethernet Ok). Otherwise the motors will induce glitches. This and other reasons is why industrial/automotive/lab equipment
typically uses CAN bus (which is basically a fancy multi-device UART). It is better with a multi-component system in
prototyping phase to have probe points in between each module which provide easy-to-read debug output - this includes points for
bus sniffing which spit out readable data, as opposed to hard-to-decypher data (ethernet not Ok). If boards are going to be
linked together in series then the communication method should best be daisy chainable (ethernet not Ok, CAN Ok).

128 kB because? The motor control algorithms take a whopping 4 kB and need plenty of room to grow I guess! (Focus on simplicity
of parts, not $ cost of memory.) Limits of hardware is not the problem, getting good developers usually is. With poor
developers it's best to make their project area small and well defined. (Tiny memory, tiny algorithms, and small isolated
components that have all outputs well tested under all input conditions.)


## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################

--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to
diy...@googlegroups.com. To unsubscribe from this group, send email to diybio+un...@googlegroups.com. For more options,
visit this group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diybio+un...@googlegroups.com.
To post to this group, send email to diy...@googlegroups.com.
Visit this group at http://groups.google.com/group/diybio?hl=en.
To view this discussion on the web visit https://groups.google.com/d/msg/diybio/-/5STRpaxxG90J.

[James Jones]

while the 3 fingers/base 3 logic is sound...

I was motivated by a more mundane chain of logic...

300mm is very nearly 1 foot, which the Brits realized whilst they retooled from imperial to metric... 

http://en.wikipedia.org/wiki/Metric_foot   The tie-in to modular coordination is a nice bonus!

And, as the reluctant inhabitant of one of the very last outposts of the un-metric frontier, I was grasping for a unit size that would gracefully accommodate metric dimensions, even with materials based on feet and inches...

Since the Cubes scale up by doubling i.e 300mm, 600mm,  1200mm etc  

I started off with a 1 meter cube but it was not a graceful size for a lot of applications (a t-shirt printer will not accommodate large shirts in a 1 meter space for instance) so that and a few other considerations is how I ended up with the slightly weirder sizes

James 

diy...@googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com. For more options,

visit this group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.

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

To post to this group, send email to diy...@googlegroups.com.
Visit this group at http://groups.google.com/group/diybio?hl=en.
To view this discussion on the web visit https://groups.google.com/d/msg/diybio/-/5STRpaxxG90J.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Cube Spawn" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cube-spawn+unsubscribe@googlegroups.com.

[James Jones]

Oh!, afterthought: since you mention 10cm (100mm) and since the modular coordination aspect has been mentioned the next size DOWN from the 300mm cubes could be a 1/3 split to an 100mm cube as these "tunnel down" into the world of minaturization - I think tele-operating assembly machines at a scale where electrostatic forces predominate would be interesting indeed!!