Atomo started out from developing a new motion control board for another project. I saw that prototyping something that was new and complex just was not made any easier with the tools that are on the market. The sensible approach was to strap a dev board onto a protoboard and start wiring things up.
And the results are something like this. It works, but the next step in this process is to either make a PCB that works with the dev board (in this case that wasn't able to provide enough IO) or to do a full new PCB single board design. Both work, but it felt like the process was missing the ability to iterate or add things in a reasonable way.
I started thinking back through other projects I had done, and there were a few commonalities:
1. Cleanly routing or getting enough power was always a bit of a hack and took up more time than it should (this is especially for robotics or other high power things).
2. It was hard to mix together existing shields/HATs or whatever with new designs and have the result to either be a good solution or really suitable for longer use.
3. Debugging new systems was a pain when things went wrong. If a drive transistor was blown out, it was embedded in a board with many other functions that might or might not be interconnected.
I'm sure many readers here have other typical nits with existing dev boards, but I think the overall insight for me was that dev boards are pretty much just that, they usually take care of the bare minimum around the controller, but they are not made to iterate a design easily or to approach a system design in a more simple or logical way.
So, first iteration was a modular system for automation and robotics, you can check it out here: https://hackaday.io/project/13433-atomotionopencnx It was launched on IndieGoGo in September and had a luke-warm reception, but the feedback was pointing to that the approach was good, just perhaps that specific application was not the right fit.
October I went back and started looking at what it would mean to do a more broad purpose system, something that scaled up and down to be both able to make huge robots but also make simple systems that you might use a small Arduino for. We made the first working iteration of the system design then.
Having gone through this iteration, I finally really got a feel for where we were heading and designed a launch line that included improvements over this version. We went from one controller board to three, and switched from a large K22 (NXP ARM Cortex m4) to a smaller K22 and a larger K64 which were better supported with tools for flashing and the like. The smaller board based on the K22 is more or less based on the FRDM-K22 dev board, but we switched to a KL26 controller for the OpenSDA/DAPLink USB flashing interface, same as used in the Microbit.
Now, doing the design for all of these boards in 10 weeks was a bit of an effort. We used KiCAD for the schematic and layout. I had two people working on it (a contractor and myself) for the whole time. The interfaces, like the module connectors, were fixed as early on as possible, but there were some later changes that we only found after more or less completing the full round of designs. So, that 10 weeks was actually two spins of some of these boards.
In order to sort out the connections to all of the modules, I put everything into spreadsheets with checking back and forth to look for missing connections and duplicate uses of different port functions. I then generated the information for the KiCAD schematic from this and created the main components and connections in this way. By doing this, the two controller boards using the K64 were able to use the same pins between them for the first four modules and I was able to save a lot of time with keeping track of what was what. There are pin configuration tools that help validate on the duplicates side, but there are not any tools out there that do the checking between different interfaces, other than just the schematic itself.
While this was going on, I had also been doing modeling of the system in 3D to nail down practical sizes and spacings for all components and thinking through how potential casings might work, cooling, etc.
That got us through to the last round of prototypes. We finished the design just in time to get them done as local factories in China for the PCB production and assembly before the Chinese New Year holiday. And then the testing began.
It took a bit of time to sort out a few assembly issues and then there was some updating that was needed for the OpenSDA interface to work, but in the end we had a working system with all the controllers booting up.
Then I started doing a more practical project to kick the tires.You can see the controller in this photo has the connector reversed so it is pointing backwards. We found that the Pi-compatible header had been inverted so that it was only compatible when installed from the rear. At the same time, I came across this post about using the Pi as a JTAG programmer with OpenOCD: https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi/overview. So, with a little bit of rewiring, we were able to use the Pi to flash both system controllers. Which means that for Robot OS or other applications, the firmware for the main controller could be pushed onto it via a Pi that is acting as the human interface. You can see more details of the LED panel build here: http://www.atomosys.com/blog/how-the-led-display-works I'll do a separate project writeup for that.
So, we are just about to launch the new system on IndieGoGo. We collaborated with Arrow the whole time from September until now and are launching with Arrow Certified status (they have reviewed the designs and agree that they are ready for production). I'll be posting up more specs for all the modules on the atomosys.com site, but it would be great to get some feedback on this so far. We are offering an early bird discount for people that sign up on the site before the launch, so please help spread the word.