Epiphany

[Samuel Rose]

I just had an epiphany reading
http://cubespawn.com/wiki/index.php?title=Install_Instructions_Linux%2BROS
and that is that these setups and configurations could be laid out in
the http://puppetlabs.com/ configuration toolkit, and deployed in
automated ways + managed by the puppet architecture to deal with
package upgrades, etc etc.

So, if you had a whole factory full of cubespawn equipment, this would
give you a way to save tremendous amounts of time and money avoiding
the need to fiddle around with setting up and configuring each machine
(or upgrading packages, the operating system, etc). Puppet (and
similar systems) are how hosting companies manage large collections of
servers and their configurations. The same approach could work with
cubespawn, now that you are using Linux, and distro packages, etc.

The puppet approach could also speed up development of cubespawn
itself, because people could download a configuration that in turn
sets up the software in a very standard and predictable way. So, you
spend less time figuring out among developers and and collaborators
whether one person has version "x" of some library on their machine.
Puppet manifests and modules ensure it will be the same.

--
--
Sam Rose
Hollymead Capital Partners, LLC
Cel: +1-(517)-974-6451
email: samue...@gmail.com
http://hollymeadcapital.com
http://p2pfoundation.net
http://socialmediaclassroom.com

"The universe is not required to be in perfect harmony with human
ambition." - Carl Sagan

[John Griessen]

On 01/17/2013 09:51 PM, Samuel Rose wrote:
> these setups and configurations could be laid out in

> thehttp://puppetlabs.com/ configuration toolkit, and deployed in

> automated ways + managed by the puppet architecture to deal with
> package upgrades, etc etc.

I've been studying chef for the same reasons plus intermediate goal of
automating web server creation for promoting kit sales. Puppet competes.
I have not tried it yet.

[Samuel Rose]

Chef would work as well.

I work with Puppet because I am more familiar with it. And, it is a
better constructed tool with less problems in terms of errors and
"bugs" IMHO.

[James Jones]

Fire up the epiphinizer and record that thought!!

I am more than mystified... puppet? chef? OK, I'l start reading...

At some point however I won't be able to keep eating from this banquet of data...I'm getting full

My simple solution was to create ISOs or equivalent for a PC, a BeagleBone flash and an R-Pi flash with more as needed...

And I thought this could be done with VMwares cloud deployment tool as if they are VMs but I don't think ARMs are supported, so those are just flash images

But if versioning and automated installs are not unreasonably complex to make, track and deploy, I'd be (more than) happy to play along. its a great idea!

In other news

the ultimaker board if fully populated, the belts and pulleys are mounted in the machine although I'm still missing two Z axis parts and a couple small brackets for the belt ends - but the mechanical stuff looks good.

I meant to post up pictures last week, only to discover my digital camera has finally died, and my girlfriends is out on loan - so it might be cell phone pictures...

As mentioned the Ultimaker stuff is all assembled - I'll connect the motors tonight or in the morning and start testing

I have two alternative electronics designs to assemble

GRBL on an Arduino ( I have this, but it'll need motor controllers) 

and Smoothie( I don't have this yet)

I'll also be getting a R-PI shortly 

Exciting!

and sometimes overwhelming,

James 

[John Griessen]

On 01/17/2013 11:11 PM, James Jones wrote:
> if versioning and automated installs are not unreasonably complex to make, track and deploy, I'd be (more than) happy to play
> along. its a great idea!

It starts to look like a really money making factory run by 2 or 3 people...for cranking out
thousands of assemblies of dozens of kinds per day.

[Samuel Rose]

James, and John,

In Feb, if I can get my hands on the equiv. controllers, etc that you
are currently working with, I will work in Feb. to contribute Puppet
configurations (I'd do chef, but I am not familiar)

[John Griessen]

On 01/18/2013 01:09 PM, Samuel Rose wrote:
> James, and John,
>
> In Feb, if I can get my hands on the equiv. controllers, etc that you
> are currently working with, I will work in Feb. to contribute Puppet
> configurations (I'd do chef, but I am not familiar)

I've started reading about puppet some and it seems to require
a linux running to work. Or does it? If you had an ARM microcontroller
and were able to compile lwip (light weight internet protocol) into it to do
TCP/IP, what are the minimum programs to have running on it to do puppet
messages and mcollective messages?

[Samuel Rose]

John, I am still looking into this. I know that some folks at google were using puppet for chrome os on beagle bone.

As far as I know, whether puppet, or chef, or salt, etc, you run these sys admin automation files from a running operating system. So, in theory, you would run the config once the OS is booted on the device. From there, you can have a puppet master server monitor and maintain the client operating systems. I am still researching this, so don't have all the answers yet. When I do, I will share for sure (likely in the form of a repo).

[John Griessen]

On 01/22/2013 11:07 AM, Samuel Rose wrote:
> I am still researching this, so don't have all the answers yet. When I do, I will share for sure (likely in the form of a repo).

Thanks. It seems so far like some bare metal ARM M4 communication can be done via ROS, but to redo the
boot and run code over the ethernet is what we would love. May take a while, but seems like
writing a mini-OS or using onelike ecos and compiling in just the bare minimums is how that would go.

An interim way to proceed would be to develop tool code with message based programming interface
that does not need to be reflashed on auto, just send it different sequences of commands via ROS.

The ROS boards/boxes will be good ones to try reflashing on auto with puppet, or develop a puppet message-based
API for ROS.

[John Griessen]

On 01/17/2013 09:51 PM, Samuel Rose wrote:

> The same approach could work with
> cubespawn, now that you are using Linux, and distro packages, etc.
>
> The puppet approach could also speed up development of cubespawn
> itself, because people could download a configuration that in turn
> sets up the software in a very standard and predictable way. So, you
> spend less time figuring out among developers and and collaborators
> whether one person has version "x" of some library on their machine.
> Puppet manifests and modules ensure it will be the same.

Maybe I've been too minimalist and cost focused. To change the bill of materials
costs for a computer board up from $12 for an ARM M4 with 2MB flash, .25MB RAM to
$35 for an RPi with 512MB SDRAM and SD card that runs linux is not a big deal.
Each cube can have one of those without breaking the budget.

Maybe some part handling flippers and conveyor belts can use cheaper separate processors
connected by ROSserial and always used connected with a RPi ROS machine, never standalone
and there's no big cost problem.

ROSserial has arduino code. What would it take to port that to ARM M3 chips? That would help
because there are so many variants, some with DSP, some with camera interfaces, some with more PWMs, etc.
and they can all have the same low level code and compiler and JTAG code loaders
and so save development time.

[Samuel Rose]

John, can you break down the workflow you hope to automate in more detail? This will help me with research. I'll start parking it in cube spawn wiki as I go.

On Tuesday, January 22, 2013, John Griessen wrote:

[John Griessen]

On 01/23/2013 06:44 PM, Samuel Rose wrote:
> John, can you break down the workflow you hope to automate in more detail? This will help me with research.

The work flow I am envisioning, without implementation details about kinds of processors,
but a few assumptions about costs is:

Parts like printed circuit cards and components and finished enclosures are picked from
loose piles and assembled. The piles may be in bins for more blind suppliers to deal with,
but the "assembly line" I am seeing is run with vision systems that are easy to train by human
operators -- neural net based with no math of kinematics used in vision 3D mapping, just
neural recognizers done in hardware like a "chain of identical neurons comparing an incoming
video pattern with its reference pattern". The more view angles the operators program, the more
can be recognized. Those can be sorted into bins for action and dealt with. Some misses will
happen, but can be reset by random stirring or digging in the pile of parts to recognize.
Once recognized, a part can be grabbed and moved, and then the process starts over, but at a different
position. After a few moves, a part is where you want it and can be assembled. The chips
that can do these recognitions resolve to a decision in a millisecond, so there is good
opportunity to make some programmed use of those decisions for grabbing objects to move.

It's just half baked, but that's what I'm thinking of.

A tributary flow is taking in extruded rough recycled plastic, chopping it off,
handling the block into one of James's milling cubes, milling it into an enclosure,
and sending it along to the above process, and the chips to the remelt and extrude
process TBD. Also using neural vision systems as in http://www.cognimem.com/_docs/Datasheet/DS_CM1K.pdf

John Griessen

[James Jones]

Not to butt in, but I think I just read Sam asking about a puppet workflow 

and receiving a mechanical functionality workflow


which is why email will never totally replace the value of conversation

 - of course I could be mis-interpreting this - thereby inducing ANOTHER point of confusion... 

but hey....

[Samuel Rose]

On Wed, Jan 23, 2013 at 9:14 PM, John Griessen <jo...@industromatic.com> wrote:
> On 01/23/2013 06:44 PM, Samuel Rose wrote:
>>
>> John, can you break down the workflow you hope to automate in more detail?
>> This will help me with research.
>
>
> The work flow I am envisioning, without implementation details about kinds
> of processors,
> but a few assumptions about costs is:
>
> Parts like printed circuit cards and components and finished enclosures are
> picked from
> loose piles and assembled.

Ok, I see. It might actually be useful to progressively develop this.
That is to say: testing the above scenario before introducing the more
complex components below.

If you are envisioning using ROS, you can also model it with
integration testing via http://www.ros.org/wiki/UnitTesting and
rosunit (was rostest).

> The piles may be in bins for more blind
> suppliers to deal with,
> but the "assembly line" I am seeing is run with vision systems that are easy
> to train by human
> operators -- neural net based with no math of kinematics used in vision 3D
> mapping, just
> neural recognizers done in hardware like a "chain of identical neurons
> comparing an incoming
> video pattern with its reference pattern". The more view angles the
> operators program, the more
> can be recognized. Those can be sorted into bins for action and dealt with.
> Some misses will
> happen, but can be reset by random stirring or digging in the pile of parts
> to recognize.
> Once recognized, a part can be grabbed and moved, and then the process
> starts over, but at a different
> position. After a few moves, a part is where you want it and can be
> assembled. The chips
> that can do these recognitions resolve to a decision in a millisecond, so
> there is good
> opportunity to make some programmed use of those decisions for grabbing
> objects to move.
>
> It's just half baked, but that's what I'm thinking of.
>

I know that ROS has it's own visual libraries. If those are not
sufficient, there is also http://simplecv.org/ python libs that work
really well for this kind of pattern recognition (usually no 3D
needed)

> A tributary flow is taking in extruded rough recycled plastic, chopping it
> off,
> handling the block into one of James's milling cubes, milling it into an
> enclosure,
> and sending it along to the above process, and the chips to the remelt and
> extrude
> process TBD. Also using neural vision systems as in
> http://www.cognimem.com/_docs/Datasheet/DS_CM1K.pdf
>

From what I understand of http://simplecv.org/ you may not even need
the advanced neural vision systems. Check it out. Also, it's probably
worth looking at the vision already in ROS if you are planning on
using that, since it probably can do some of the same processing that
SimpleCV can do. In the end, these kinds of approaches very likely
will give you exactly what you need. There are various tricks with 2D
computer vision for recognizing patterns, without necessarily needing
to emulate a neural net.


> John Griessen

[Samuel Rose]

On Wed, Jan 23, 2013 at 10:03 PM, James Jones <data.p...@gmail.com> wrote:
> Not to butt in, but I think I just read Sam asking about a puppet workflow
>

Yeah, I was specifically wondering on a controller level (if you are
using beaglebone with linux, for instance) what the workflow typically
is for installing the operating system, and then the packages etc.
Because, that is where puppet can intervene and get packages, OS
configurations, etc set up in an automated and consistent way.

> and receiving a mechanical functionality workflow
>

That is true, but it was educational anyway, so not a huge deal.

[James Jones]

I can only guide you to:

http://cubespawn.com/wiki/index.php?title=Install_Instructions_Linux%2BROS

for the workflow I used on the beaglebone - although its not tested yet

which mostly came from here:

http://www.ros.org/wiki/fuerte/Installation/Ubuntu

I also went here

http://quadrotordiaries.blogspot.com/2012/06/installing-ros-fuerte-on-beaglebone.html

which took me here

http://www.ros.org/wiki/fuerte/Installation/Ubuntu/Source

I found a shell scripted install

http://people.mech.kuleuven.be/~kbuys/embsensor.html

but haven't tried it yet

for the steps used to create a flash image on another machine

to get Debian on ARM + ROS

those are all the resources I've explored so far

[James Jones]

forgot to paste the last link :

http://www.eewiki.net/display/linuxonarm/BeagleBone

[John Griessen]

On 01/23/2013 09:12 PM, Samuel Rose wrote:
> From what I understand ofhttp://simplecv.org/ you may not even need

> the advanced neural vision systems. Check it out. Also, it's probably
> worth looking at the vision already in ROS if you are planning on
> using that, since it probably can do some of the same processing that
> SimpleCV can do.

Thanks I'll give it a look, and those approaches
seem to require a lot of logic programming --> complexity. They need processor power also
I think. The neural hardware chips do comparisons for decisions super millisecond quickly
with no external processing power drain and cost $100/chip in low volumes, but would come down
if volume went up. If you want to save and reload trainings, that is data to
move around and would be good to encapsulate with puppet scripts and ROS code.
The neural chips are probably far off since they would need board design and save/restore trainings
code-- I'll try reading up on ROS vision.

I'm still in the middle of lots of unrelated work for months is the trouble with
me researching things. It'll have to be practical -- can't afford time til
after the construction project.