Xi and Flux

I did promise to give everyone an update on our Xmos dev work and let you folks know what became of Amino, apologies for the delay I have been busier than ever over the last few months. XiAfter several years work and experimentation with project Amino I (as well as others) have yielded some interesting new development platform ideas, we have also gained a great deal of experience using Xmos and modular multicore technology.Fluxxi As you are probably aware, much of my recent opensource hardware development has been focused on motion control applications for CNC and 3D printing applications, it will therefore not come as any surprise that I have been working on a a unified rapid prototyping system for these new motion projects, rather than the disparate microcontroller dev kit based approaches that I have been struggling with in the past. Thus I took much of what I learnt from Amino and my other projects combining them to create Xi which is a 2D and 3D modular board prototyping system that we now use for internal product design here at Folknology Labs. In its 2D mode it can be used rather simply with up to 3 small breadboards for rapid experimentation as shown in the first picture, Alternativiely it can be combined with up to 3 plugin modules like the Fluxxi (a hybrid motor module) to create a motion control combos. These Xi modules along with either a debug or communications board snap together form a cube with sensor and actuation connections on the rear of the assembly. This approach also enabled us to overcome one of the early Amino design flaws of physical strength and support. These modules when combined into a cube can also be housed in rectangular housings like angled steel and ALU or just held together with 3D printed corner joints for rigidity. If required these can also be expanded into a star topology with multiple cubed controllers using Xmos links for channel based development. We can make some kits available if anyone is interested in experimenting with the Xi for their own projects or simply want to kick the tyres, if so leave a comment or get in touch via the usual methods and we will endeavour to get you some Xi early access action, who knows you might even want to create your own modules.

Cartesian & delta robots, RepRap and a new hackerspace

I know its been quiet on the blogging front here for a while but that doesn’t mean a lot hasn’t been happening, I’ve had my head down in a number of projects, I need to rebalance my IRC, Twitter, usergroups and everything better! After meeting some 3D printing folk at OggCamp last year we decided to form a RepRap group for the Thames Valley area along with a build group within that (TVRRUG). I took a lead on the electronics side of the build as we couldn’t find a suitable design that met all of our group requirements. Ironically given the percentage of self builds occuring within the RepRap world most of the electronics designs are not adapted to through hole components, many use the Allegro QFN stepper drivers (amongst other SMD choices). In addition the electronics are often not designed with beginners in mind and are not modular allowing makers to build in testable sections. So we have spent the last 6 months or so designing, building and testing a modular through hole RepRap electronics set which has proved to be an interesting diversion from the Amino project, it also enables me to complete my own RepRap build. The modular components make up an opensource set of stepper based cartesian robotic controls and is starting to find interest outside of just RepRap builds but also CNC, plasma and laser cutting applications. Given the community nature of the project I decided to explore a new online service aimed at hosting hardware projects called SolderPad started by a couple of my OSHUG colleagues. You will find a number of my opensource projects listed at SolderPad, which incidentally makes it easier to embed stuff here (in theory but lets see how it works out).

Open Motion Controller
Open Motion Controller
Dual Stepper Module
Dual Stepper Motor Module

While talking about community stuff I should also mention Reading Maker Space (RMS) which is a new hackerspace in the Thames valley we have been bringing into life, I have already run some soldering classes there for the TVRRUG folk and others. RMS is on the cusp of going live as we speak just as soon as the RFID door system is in place, if you live in the Thames Valley area and are interested we run open days on Wednesday evenings where you are welcome to come and check out the space. There are already some great folk involved in RMS especiallty Ryan who stuck his neck out by putting money down on the space itself. At RMS there is already part of the TVRRUG crew contigent for that project and I am also getting involved in a delta robot project along with some of the other planned activities like polar robotic controls for things like robot Arms etc.. I am sure that there will be many more interesting projects emerging from RMS over the next few months.

I haven’t yet got Amino onto solderpad as have a fresh new design version in the pipe. The new design simplifies some of the board layout issues of the previous version and adds some Xmos backward compatability for my add ons, it also solves some of the physical issues I experienced with the last layout. The result will be something simpler, compact, expandable and more practical, I’ll have a lot more to report on this very soon. At the same time I have made some progress on the software side of things and now beleive I have found something more unified in my approach, again more on this shortly.

P.S. I will be talking at OSHUG 16 on Thursday along with some other interesting OSH folk, worth attending if your in town

iBOM Part 4 – Expanding the market

Production on the backend isn’t the only thing holding back opensource hardware, getting from innovation and good ideas into any sort of distributed production requires initial investment. In some cases it can be very small, but unlike opensource software there are physical requirements of pcbs, parts and tools that have very real costs! the iBom part of the equation could be connected in here also by the likes of an Octopart, either by aquiring someone like KickStarter or by rolling their own distributed investor community. This would have the effect of ‘quickening’ the front end in order to supply the backend and would facilitatte the emergence of a ‘Market’ which is the next key part of the move to distributed production. It doesn’t take an Einstein to take this further and envision market places bolted onto the innnovation front ends for successful projects, thus closing the circle and providing positive feedback whilst encourage fresh new agile growth.

*Update I added an iBom repo to get started on the idea/format etc..

iBOM part 3 – Reinventing Production

So in this new world of iBoms and meta-iBoms what changes? Well pretty much everything, electronics construction gets dragged kicking and screaming into the 21st Century. Open Hardware production becomes much more simplified and distributed. But why should Octopart do such a thing? Well they could pull a Google on the Electronics supply chain for a start, that’s got to be worth something? We get great footprints and metadata, our opensource tools (Kicad/Geda) would improve significantly I would expect it would be in the interests of say an Octopart to invest into those tools and help devolop them. I could even imagine Octopart buying Github and integrating project management into the whole iBOM, pretty soon it would mean that the buyers would start stearing the component manufacturers/vendors indicating whats needed to be made to make our lives easier rather than the dictorial arrangement we currently have with them. It will also change how things are manufactured in general, with the combination of this and 3D printing technologies (RepRap et al) things could be produced nearer their destination rather than being shipped half the way around the world as they currently are (highly in efficient). That sort of change could make huge differences to the future economies of not just electronics but manufacturing itself.

iBOM part 2

Ok so say we have iBOMs, this in itself could be extended further to make it even more powerful. Imagine that all of the items in an iBOM could be iBOMs themselves from individual components through to component modules and entire projects. Then we would be able to assemble modular constructions of arbitarly complex parts we would even be able to create Meta Projects with meta iBOMs. So how do we get there, how do we get components and modules as iBOMS? Well the modules could be fairly simple as they are in control of those creating the OpenSource Hardware projects (and opensource sofware iBOMs), the tricky piece is the individual components. Well I have several ideas here; if Octopart were a third party iBOM operator they could start creating iBoms for all available components. Sure this sounds like a lot of work and they probably couldn’t do it all themselves, they would need help from the community. Here is one way they could incentivise the community. They could create a standard component description file (a component iBOM) that also included additional useful information. This could be used to not only identify the component but also produce/derive the various footprints for the component using a standard opensource tool/script. By doing this the iBom file for the component could be used by various CAD packages to bring in valuable footprint databases much needed in the community. Octopart could create a database of popular component iBoms for the open source community (ones commoly used like Atmega328s) to kick start the open iBOM DB process. That would encourage their use and also encourage others in the community to start adding their own iBoms back to the open iBOM database (basically component iBom files on say github). If the iBOMs were done correctly to also capture contextual information like the component usage (used in production) and quality (peer review/rating) perhaps a contextual metabase over the top could add qualative selection criteria magnify the iBOMs worth, this would provide confidence in the iBOMs use for a designer and proliferate there use.

Part 3 coming shortly..

Thoughts?

Intelligent Bom

iBOM Part 1

I found my self in conversations recently around the progression of OpenSource Hardware development and moving it’s production forward. I have long been interested in distributed open production and have talked about this for some time. In a recent conversation with one of my colleagues (Ken) about how his project Nanode could be moved forward and made more accessable to a larger audience. We were wondering in particularly about solving the production problem, in the nanode’s case it was kit based. We came to the conclusion that it would be cool if we could produce a BOM as part of the project that would be more enabling to potential participants in the project. I suggested to Ken the idea of an hyperlinked BOM, in it’s simplest form being a link to a preloaded basket at different distributor suitable for each geographic location. After thinking about this some more I came up with the concept of the Active or even the Intelligent BOM (aBOM/iBOM). with an iBom you basically have a hyperlink (hBOM)to a web based service which takes a standard BOM, creates multiple baskets and chooses components from a range of suppliers and best choices. It could also offer basket optimisation like cheapest, or fewest suppliers etc.. dependent on the BOM contents and or quantities/preferences you might provide. For it to work you would provide a standard file format BOM text file in your project repository (on say github) you could then create a REST based link to the thrird party iBom provider e.g.

http://ibom.com?source=github.com/myproject/mybom

Whe the user clicks on this link they are taken to the third party and presented with various competitive baskets to buy the projects components (or vitamins as RepRapers call them!). You could even produce PCB with the URL (even QRcode/barcode) on them so folks can populate them more easily, or produce the PCBs themselves and then populate using the iBom.

So who could provide such a third party

I will expand this further in Part 2

Would love your thoughts as usual..

Amino Clarification

The Amino Project has evolved over the last couple of years from a need for higher performance and modularity than I could find in the opensource hardware world. Turns out I was far from alone in my desires for such a solution. Although initially I worked on possible ARM based solutions when others expressed opinions that strategy changed and we adopted Xmos as a core part off the architecture. In between those periods I was hoping to use FPGA and MCU combinations but a conversation with Omerk back in November 2009 moved the conversation onto Xmos. But we would like to indicate that this isn’t the final chapter for Amino on the architecture front and in the background we are still exploring both FPGA, MCU and Asic approaches to solving the issues we face in modularity and performance at this level.

This brings me to the point of this post then which is the clarification of what Amino really is. It is all to easy to let Amino’s scope drift away from it’s initial goals and become either to specialist or all to encompassing. So we would like to make a clarification for Amino going forward. In addition I would also like to clarify Folknology Lab’s role in Amino.

Amino is primarily concerned with the definition of a hardware interface. This will allow modular hardware components to be mixed and matched in order to build hardware prototypes, applications or solutions. So Amino’s primary documentation and focus should be concerned with the interface specification which is something we are working on and hope to get something concrete out shortly. In order to reach a point where this makes sense Folknology Labs has been building experimental open implementations of the standard. In this regard Amino Beta is purely an experimental Implementation on the Amino interface specifications, it does not represent a shipping or commercial product. Indeed anyone can and should make Amino compliant products, be they blades or boards that house blades. we also need to state that Amino does not decide the exact form factor of a blade or a blade holder, rather it concentrates on the pinout function and spacing. Thus one can for example have horizontal blades, indeed Folknology Labs has several design of this type for housing single or double horizontal blade configurations. However if more than 2 blades are required to be attached to a single board then a vertical arrangement is clearly needed, hence the initial design of Amino Beta using vertical blades. This has been asked about quite a lot by the way..

Obviosuly Amino interfacing is primarily about the hardware interface specification, in order to make these blades work together with different Amino boards however, there needs to be some standardisation around software, as well as the electrical characteristics. Initially this will be based around Xmos toolchains as that is the initial architecture used for the implementations but it is clearly not confined to that, later we hope we can expand this across other architectures whilst maintaining the benefits of a common interface.

One of the things we need to do after testing Amino Beta is make an initial release of documentation and implementation examples in a common area for everyone to access and perhaps participate in if they feel passionately about the idea. My initial idea is to use Github to house the project and use opensource tools where possible to create implementation examples. Amino Beta by the way was created in Eagle and we will release those files as part of this process, however we are trying to move everything over to Kicad (including our libraries) which will better support version control process provided by git, this is due to Kicad’s use of open format and text files unlike Eagle’s more restrictive binaries. We Cannot guarantee That Amino Beta will be ported as it is just a first example (porting is a lot of work), but future implementation examples will most certainly be created in Kicad.

We also hope to finalise the electrical and physical Amino interface standard by the end of March so that we can focus on implementations and software ASAP, clearly if there are any changes you wish to put forward or include, now is the time to do so.

Where does Folknology Labs sit within this? Well Folknology Labs is likely to create its own implementations of Amino and see it as an important part of its hardware and software strategy moving forward, but that doesn’t represent a reference implementation, rather it would represent Folknology Labs implementation, in other words Folknology Labs != Amino or vice versa..

So please let us know your thoughts on moving Amino forward, should we use github or some other method? how would you like to see Amino move forward, what sort of license should we use etc..