Stephen TranovichHi! Greetings from Estonia!
And from Africa
Hello @tanel !
Hello @murray !
A big welcome from San Francisco!
and from Bosnia !
Epic locations abound!
Seattle :)
:)
Okay, let's get started with this international conversation!
Amazing how hardware connects people all over the world
Everyone, throw your questions into here for Asaad to answer! https://hackaday.io/event/159924-making-modular-hardware
It really is amazing!
Okay, to get started, @Asaad Kaadan , can you introduce yourself and tell us a little about your background?
Hi all
sure! thanks for inviting me and welcome everyone!
I'm embedded/robotics engineer currently in Seattle. My day job is with Freefly Systems building drones / robots for the movie industry
Hi @Boian Mitov . :-)
I have a passion for modular electronics which is my weekend and night shift with Hexabitz
It started when I was working on my phd at the Univ. of Oklahoma
Hi @sfrias1 :-)
Awesome chat with Asaad.
Thanks @sfrias1 and welcome to the chat!
And can you tell us about Hexabitz? What it is, how it started, and where it is today?
Hexabitz started first as a way to mimic natural shapes to get the most abstract modular electronics design.
I was fascinated by how nature uses modularity to build complex flat and curved shapes
Tracing that into basic mathematics of hexagons, pentagons and triangles etc
My phd project was about building a pixelated optical communication device that was following these concepts
Later however I went back to my love for electronics and decided to explore same concept for a modular electronics system!
Have I missed it?
We started with few module designs and gradually built more hardware and firmware
We just launched our online store on our website few weeks ago... It's VERY work in progress but finally we have about 14 different modules ready to see the outside world!
Modules - Hexabitz
3.3V / 1A DC-DC Buck Power Supply With Terminal Block Input
There are more planned and lots of work on both hardware and firmware side. So I say it's taking shape slowly!
I haven't had chance to build lots of demo projects yet. Trying to balance hardware / firmware dev, documentation, examples, etc
Congrats on releasing those first modules!
But we're excited to share with the community and start getting feedback and seeing modules in the wild!
Let's jump into the community questions now! If any of you have a question, throw it into the discussion section here: https://hackaday.io/event/159924-making-modular-hardware
Since we're already on the topic of your newly released modules, let's jump in with this question: How did you choose which modules of your modular prototyping platform to develop first?
Thanks! Definitely still a lot of work to be done but we're progressing
I started by surveying about 40-50 projects and finding out the most used functionality there
I made a list and started going through them from the most used ones
As you expect most projects for example share RGB LEDs, relays, wireless modules, etc
I tried to stick with the schedule but naturally some modules got ahead of each other!
Still our first batch would enable many different projects and we're adding more. People always send u useful module suggestions and it's really difficult to choose which ones to invest time and money with!
I can see that! Choosing which features are critical is the challenge in most hardware products and dev platforms.
Our next question is from @murray with regards to the relay hub project video at the bottom of the event details: From the video it looks like the configuration is "found" once and after that the routing is static, is that the case? And is the system communicating in a active redundant way, ie along more than one path at a time?
But we have ambitious plan to build a large number of modules byond just the most common ones
Good Q @murray! Yes right now the array configuration is static. But you can erase it, change the array shape and discover the configuration again
WHat we would like to do in the future is to learn more from wireless mesh networks and make topology discovery a dynamic real-time process. It will also help in detecting malfunctioning modules
As for routing, right now it's using shortest path routing via Dijikstar's algorithm
You can definitely create multiple independent routes in the array
let's say modules 1 & 2 talking to each other and 4 & 6 talking to each other at the same time
our operating system is still experimental and not very robust in complex cases but it'll evolve and get better with time
You can also broadcast a message
or send to a specific group
let's say you target only the group of relays with turn on message, etc
This is all handled in the backend. You just build the message and choose its destination and the backend OS will handle routing etc
Next Q?
Ya! We've got another one from @murray : Why the chosen license as opposed to GPLV2 ? The project resembles a software comma library after all?
I'm not expert on open source licenses but I wanted the project to be used commercially as well
I think with GPLV2 you have to open source all code unless there's a modified clause? Again not sure
But MIT license is really cool
Has most GPL stuff
but if you have a commercial application you can take our code add your own and keep it closed source
No GPLV2 can be used anywhere, but if anyone improves on your code, ie routing etc, then they are expected to return that back to you.
kind of like a library that can be added to anything, but if you improve the library itself, then please share...
I see. Some people might sense that as limitation. We definitely want people to contribute and improve
But if you improve on your own and don't want to share that's fine (most commercial applications are like this)
Linus Torvald's specifically saw GPLV2 as a reason for linux's success as it prevents fragmentation of the core.
Good point
Let's hop on to our next question that's coming all the way from Estonia! @tanel asks: Any recommendation for modular HW involving high speed and throughput sub-systems? We have used CAN and RS485 for different node based complex systems, but if video or lidars get into game then Ethernet and USB are still the only ones to go?
But when there's a hardware platform I think fragmentation is less concern but I might be wrong
I agree both CAN and RS485 are limited throughput.. Are you talking about a long range communication or like a modular embedded device?
For longer range I think all variation of Ethernet (profibus), etc are the best
Not sure if USB is helpful in networking. It's not supported natively.. For a small embedded device may be PCI express or a custom bus
For embedded devices I'm also in favor of using simple serial ports with high speed arbitration / buffer management done in FPGAs
I'd like to see that in Hexabitz someday. It's kid of the ultimate progression of this concept of serial ports and DMAs
any more Qs?
This next question is @Lutetium 's and then some. Are there any use cases you have in mind when developing this platform and its modules? Are there any use cases you anticipate a wired mesh network being a particular boon for?
Yes I was shooting for ultimate configurability and modularity
when you have a decentralized wired mesh you can literally change any module without affecting your overall architecture / code etc
Imagine you built a device with Micro USB interface and last minute you decided actually USB C might be better or Ethernet is needed there
Since it's a decentralized system and they all share same backend you can replace the module in minutes. Keep your entire code intact and replace a few interface functions
That's epic.
The wired mesh also gives you ultimate freedom in configuration. You are not limited with physical form factor of the main MCU or number of GPIOs available
You can rearrange you array (board) shape to fit any new requirement and your code is 99.9% the same!
I look at it as a small logic blob embedded in each PCB
Basically I was trying to build PCBs the reconfigure themselves but do it the cheapest and fasted way!
That's inspiring!
I think in the future we will see a PCB technology that auto configure it's routing
:O I can't wait for that future!
But not in a the next decades
Me too!
Okay, we have one final question for this chat.
How does the system cope with a module or a comms line failing? Does it dynamically reroute? is there a timeout? Are the participants alerted that the system is limping?
Well not yet! But this is an awesome feature I really want to add. RIght now routing is fixed with shortest path and there are timeouts and stuff but no intelligent routing
Again this is something I'd like to learn from wireless mesh network where they detect malfunctions and dynamically change their topology
It's a fancy thing to think about right now. We have to build the basic blocks first and build the front end the does the actual useful work
But we have lots of plans to improve the backend. First things we did is the array exploration and auto configuration which saves you ton of work and errors
We also need to keep optimizing for small MCUs
Memory, clock, power constraints etc
Awesome. With those hopes of a dynamic PCB future this chat has come to an end. A HUGE thank you to @Asaad Kaadan for coming on and sharing your work and vision with us!
Thanks Asaad!
Thanks for your time @Asaad!
Thank you guys! Really great chatting with you all. It's a long journey ahead but we're excited to see modules in the wild and get feedback and ideas from awesome people here!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.