this is part 4 of my requests for improving acceptance of parallella. first and foremost I requested a for maximal usage of the epiphany-chip. next a for actual self-test and for circumventing hardware failures when you use lots of eCores. last I suggested an and one which is supposed to allow the 3-eLink Parallella to do 2-way communication through the additional eLink cable.
the idea of all these was to get a binary tree of parallellas where each epiphany can access at least 9 other epiphany chips through eLink and some kind of memory-management interface. and of course all that could work with 1024 cores per epiphany too, although then only 512 of each neighbour's neighbour's eCores would be visible. now imagine robot-modules, of different shape and functionality (or maybe all tetraeder-shaped as I suggested) taking care of each other, exchanging energy and data, working around hardware failures and altering eachother's bootstrap code. clearly through the wide transfer-routes parallella is the ideal solution for a robotics project that makes use of multiple autonomous modules. each module could have up to 3 neighbours, and in case of emergency it could take over part of their functionality. parallella would be like neurons. transfer-speed of up to 1G/s per path, low power consumption, each module operating its own sensors and output-devices, as well as its own batteries and power-harvesting methods. naturally current parallella cannot do that, some electronics is required, especially the scalability-adapter to allow for more than 16 modules being connected by eLink. porcupine board is a good start, but here my own suggestion for a robotics-friendly version:
1) in addition to address-translation the eLink interface should be reduced in connection-requirements, 60 cables is too much and too error-prone. of course in doing that the transfer-speed should not decrease, some lag is acceptable though.
2) if there is no 3-eLink parallella, create one by using the fpga-connectors to reach the 1G/s transfer-speed. provided you have 1) fulfilled, it should be possible that both are using the same connectors and cables, so that fpga can be attached directly to epiphany eLink of the other module. afaik it's possible since fpga can transfer far more than 1G/s.
3) also with fpga the actual data-path should be determined, deciding by software which neighbour received north which south and which the 3rd connection. so the board should be controlled by some bits sent through software, altering the direction of various connections on the fly. this way one neighbour can be disconnected while all other modules are still running and taking over its tasks. quite naturally swapping north with south also requires hardware reset and position-change of those neighbours. jtag and all these board-controlling pins must be connected to all of the neighbours.
4) usb, hdmi, network connectors, they all should be controlled by that addon-card. maybe this module has a driver for a device attached to a far-away module's usb-port? maybe the network software is in this module while the actual connection is elsewhere? or maybe display stuff from this module on some small part of a huge screen connected on another? some kind of translation from a framebuffer-grid into a coherent image of large size with newest hdmi technology would be nice. how about combining multiple usb2 into one usb3?
5) memory-management and power-exchange. each battery has its own connectors. use AA or AAA batteries which are rechargeable, and monitor their individual charge, and how much charge they can still hold. all that data must arrive at this module's parallella, and it should be able to turn on charging or fast-charging those batteries from the power provided by the neighbours and/or some power-input managed locally. of course also some connectors for power-sources like photovoltaics or mechanical forces should be available and easily configurable from software so to monitor their usefulness and to control where to put that power. power created or stored in batteries should be available to all neighbours, and they in turn should be able to pass it on to theirs. the network of robot-modules should work like a city of power consumers and tiny power-plants.
6) connectors for some motors or other components, with software-controlled current level and polarity. isn't an electro-motor also a power-source? what about piezzo? there definitely should be a way to switch between power input and output, some way to harvest even static electricity. of course a motor will need much more than the 10W parallella can take, some components will require different voltage, or maybe even height of voltage is a way to control their functionality. all this likely can be solved in a general-purpose board so the "kids" only need to attach the component and inform software of its specs. offer monitoring for power-consumption so software can organize the most efficient use of available power-ressources. the goal should be, without hardware-knowledge a few wires are to be connected and whatever programming then can immediately start, the hardware should take care of every thing else, with the help of software drivers...
7) optionally make a decision for an actual connector that can be used by the module autonomously. if 2 modules are in the correct position, they should be capable of grabbing eachother and establishing a connection. I suppose such a thing already exists, find it and offer it as part of such a board...
ask here if anything hasn't been made clear. the goal here is to attract robotics students and eventually AI programmers to give the robots some decentralized brain. if everybody owns such a robot-module, multiple people can meet to connect theirs into something bigger, parallella-sales would go through the roof, compareable to invention of small cell-phones and such...
modular robotics board
by piotr5 » Thu Nov 05, 2015 9:38 am
- piotr5
- Posts: 230
- Joined: Sun Dec 23, 2012 2:48 pm