coatnet
 
 

E-textile Based Imaging Array: Phase One

Introduction

This web page describes the work done on the first phase of the project and the results obtained. Much of the work carried out so far has been on the familiarization of the simulator as well as setting up the code base for the imaging array. The algorithm for the imaging array has also been implemented.



The Imaging Array

Imaging Array

Configuration
  • The Imaging Array consists of a 5-by-5 grid of processor/sensor nodes. Each node is connected to 4 adjacent nodes, except those at the edges.
  • The communication channels are connected in a point-to-point manner. Nodes can only send messages to adjacent nodes to which it is connected.
  • A node is “aware” of the orientation of the array. It knows which is its top, bottom, left and right communication channels.
  • All nodes have a unique ID that is “embedded” in the nodes. Each node does not know the IDs of other nodes at the onset of operation.
  • Each sensor is mounted with its axis perpendicular to the plane of the array. It provides only the distance of the object directly in front of it.

Algorithm
Each node will run the same algorithm. The objective of the algorithm is for a node to collect all the sensor information of the nodes in the array and put them together. Thus, eventually, all nodes will have the entire “picture”.

From a practical point of view, it is not really necessary for all the nodes to have the entire “picture”. In fact, trying to achieve this actually strained the network since data sent by each node will have to reach each and every other node. At this stage, the algorithm does not need to be too concerned about routing of sensor data and reliability of the link. The advantage of flooding each node with data from the entire array is that every node can function as the collection point of the image. This represents the “best” scenario, with maximum possible redundancy. However, as the project progresses, this might be “scaled down” to allow optimization of the power consumption and communication requirements. Eventually, only one node or a few nodes may have the entire “picture”.

This is achieved in several steps:

Getting to know the neighbors
The first thing for the node to do is to find out who its neighboring nodes are. The node will transmit its own ID to all its neighbors once. It will receive the IDs of its neighbors but does not pass those IDs to other nodes. If it does not obtain a response from all 4 neighboring nodes, it will request for a resend of the IDs. Eventually, after a fixed number of retries and if it does not receives any response from a particular node, it will consider that node dead.

Mapping the location of all the nodes
Once the node is aware of its neighbors, it will broadcast this information to all its neighbors. When it picks up such information from other nodes, it will also retransmit the information to all its adjacent nodes. It will process the information as follows to map the IDs of all the nodes:

The node will first assume that it is in the middle of the array. It will put itself in the middle of the array and all its neighboring nodes. When it receives an information packet, it will check if the center node is already contained in the array. If so, it will update the array with the IDs of the neighboring nodes of that node. This process will repeat when each packet is received until it has the entire array filled up. In the case when the center node is already at the edge of the array, but still has neighbors, it will shift the array in the opposite direction. The node will stop transmitting its own information once it has the entire array filled up.

Sending out own sensor data and getting data from all other nodes
After the node has the entire array, it will start transmitting its sensor information. The sensor information packet consists of the node’s ID, the distance information as well as a time tag. When the node receives such information from other nodes, it will broadcast the information to all its adjacent nodes. The information is checked to see if it is an updated copy based on the time tag. If it is, the distance value is updated in the image array. Otherwise it is discarded.

Implementation and Simulation

Setup and Configuration of the Simulator
After obtaining the source codes for the simulator, the source codes were compiled on a x86 Linux machine successfully. Based on the layout of the imaging array, a script file was written to configure the simulator. The simulator is configured to set up the 25 nodes interconnected by 40 network segments.

A sample of the script file contains the following components.

Network segment initialization
The network segment is initialized to a unique segment ID. All network segments are initialized to have no failure probability.

netnewseg 1 1024 300000000 1600000 0 0 0 0 0 0 0 0 0
netsegfailprob 0 0.0
netsegfaildurmax 0 1000000

Battery initialization
Batteries are set up.

newbatt 0 1.0

Node initialization
Every node is set up with no failure probability. A battery is attached to each node.

newnode 0 0 0 0 0
nodefailprob 0.0
nodefaildurmax 1000000
battnodeattach 1
battalertfrac 0.8
ebattintr
cacheoff
ff
clockintr

Connecting Nodes and Network segments
After all the nodes and segments are created, they are connected according to the topology map.

netnodenewifc 1 0.1 0.1 0 0 0 0 0
netsegnicattach 1 21
netnodenewifc 2 0.1 0.1 0 0 0 0 0
netsegnicattach 2 1

Loading the code and run
Finally, each node is loaded with an identical copy of the code. The run command get the code loaded into memory but a separate on command is needed to start the entire array together.

srecl img_array.sr
run

Simulation Results
In this phase, most of the simulation runs carried out were used to debug the program. There were some issues that arose which needed to be investigated and resolved before the final image can be constructed.

One of the main problems faced in the simulation is frames collision between nodes sending out network packets. This happened when all the nodes attempt to transmit at the same time, which was highly likely given that they all run the same code.

One approach to solve this problem is to use the ID to set up a delay time between nodes transmitting. A random back-off algorithm is also put in place to randomize the transmission so that frame collision is minimized.

Another parallel approach is to find ways to minimize network packet transmission. This has dual benefits, reducing frame collisions and reducing network loads, which potentially can reduce power consumption.

Another problem faced is the “Trying to draw water from empty well” syndrome. The name comes from the simulator messages produced during the simulation. It has to do with reading data from the buffer when there is none. The problem is not resolved yet and work is ongoing to fix this problem.

During the simulation, some of the nodes were “mysteriously” killed. The reasons for the fatal error on the nodes are still being investigated. One possible source of the error could be in the configuration of the script file in setting up the simulator.

At the moment, it took a while for the nodes to reach convergence, i.e. for them to identify their neighbors and construct the ID map. In all the simulations so far, most of the nodes can only complete the neighbors’ ID detection and with some nodes began broadcasting their neighbors’ information. Due to the “dead” nodes and frame collision, the nodes were not able to begin transmission of sensor data. This is because the criterion currently set was that a node has to have a complete ID map before it can begin to transmit its sensor data. The criterion may have to be removed.

Ongoing Work for Next Phase

Following from the work that is established, the work scope for the next phase is as follows:

  • Refine the algorithm and simulation such the all nodes would be able to build up the image array.
  • Evaluate power consumption of implemented architecture.
  • Explore and implement different ways to reduce power consumption.

Conclusion

The configuration of the imaging array has been defined. The basic code has also been implemented on the Myrmigki Simulator. Further testing would be done as the team proceeds to the next phase.

References

[1] “A Survey of Technologies for Smart Fabrics(Computational Textiles), DRAFT, Summer 2001”, Phillip Stanley-Marbell

[2] “Project proposal, E-Textile-based Ultra-sound Imaging Array”, Seng Teck, Sing & Chee Wan, Teng

[3] “Myrmigki Simulator Manual, Release 0.1.ece743”, Philip Stanley-Marbell.