Fwd: Cubespawn group is working on parallel concepts now

[Bryan Bishop]

From: John Griessen <jo...@industromatic.com>
Date: Thu, Feb 21, 2013 at 8:52 AM
Subject: Cubespawn group is working on parallel concepts now
To: biocurious-ro...@googlegroups.com

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.

http://cubespawn.com/wiki/index.php?title=Main_Page
"System Overview

The CubeSpawn system consists of Cubical frames made from aluminum T-slot extrusion.
The modular frames are built to enclose various manufacturing machines, such as a CNC milling machine, or a 3-D printer, or an assembly robot. The frames are based on a consistent dimensional framework of 300mm increments and can be linked together, each is an Ethernet appliance, with integrated power connections.

In this way, up to the limits of the ratings in each branch, cubes can be joined together to form "production lines""

[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.

[Patrik D'haeseleer]

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

--
--
You received this message because you are subscribed to the Google
Groups "BioCurious" group.
To post to this group, send email to biocu...@googlegroups.com
To unsubscribe from this group, send email to
biocurious+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/biocurious?hl=en
 
---
You received this message because you are subscribed to the Google Groups "BioCurious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biocurious+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[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.

[Bryan Bishop]

On Fri, Feb 22, 2013 at 1:18 PM, Tristan Eversole wrote:

If I have only have time to follow *one* of the email lists about lab automation, which one do you think it should be?

this one:

https://groups.google.com/group/diybio

- Bryan
http://heybryan.org/
1 512 203 0507

[Jonathan Cline]

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
########################
 

[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?

[Nathan McCorkle]

When are ANY of the lab automation groups meeting at biocurious? I'll
be in SF next week from Monday through Saturday.

> --
> --
> You received this message because you are subscribed to the Google
> Groups "BioCurious" group.
> To post to this group, send email to biocu...@googlegroups.com
> To unsubscribe from this group, send email to
> biocurious+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/biocurious?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "BioCurious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to biocurious+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
-Nathan

[cameron]

The one lab auto group meets Sunday mornings from 10AM until about 2 or 3PM. Next Sunday, the group will be installing the stepper motors on the gantry frame.

Cameron

[Jonathan Cline]

I don't, but you could check cubesat which has a similar project name to yours ;-D  They have a CAN bus communication protocol (check wikipedia's cubesat entry http://en.wikipedia.org/wiki/Cubesat_Space_Protocol ) which has defined byte format.  CAN isn't an app, it's a communication channel, so you need a communication protocol that's standardized and scalable to whatever devices you might end up hooking to the bus.

Also, check out EiBotBoard (" a general purpose open source PIC18F46J50-based motor controller board") which is a UBW board married to a couple motor controllers: http://www.sparkfun.com/products/10025
I use UBW boards frequently of course (coworker just bought another 10 for the project I gave him; basically he blows away the UBW main firmware and writes his custom firmware -- it is very fast to develop firmware with the UBW board/bootloader) and this EiBotBoard might make a good pump controller with similar setup.  Yes, Yes, these boards could be made in-house cheaper than sparkfun's price, at the cost of time and effort which might be better spent working on the next project, so we just buy from sparkfun.  The UBW board is compatible with win, os/x, linux so the EiBotBoard is too.