2/04/2015 – Mesh Visualization Two-way communication
This week we were able to deploy a lightweight web server on the raspberry pi node as well as deploy a single-threaded, non-blocking, scalable web server/web application framework called Tornado on the machine storing the postgresql database.
Through this, we were able to toggle an LED on the raspberry pi using a button as well as update its current status on the central postgresql database, through a RESTful API. This current state would then be reflected on the Unity program that we set up to visualize the status of the node.
We were also able to toggle the LED on the raspberry pi through a request from a REST client to the centralized server. This server would receive the request from the client, and forward the corresponding request to the raspberry pi which would engage the raspberry pi to toggle an LED and update its state in the database through a request to the server. In order to achieve this, we needed a scalable, non-blocking, single-threaded web application/web server in order for the request to the client to avoid hanging.
The focus of this week was on setting up two way communication with the current system. To do this, ray casting was implemented in Unity. To do this, we had to make a slight change to the NodeClassMono method. Now, when the object is instantiated the ip address of the node is stored in an instance variable. To do this, a join is made in PostgreSQL using the transaction_id of the node. This allows us to pull the ip address of the node from the database.
Ray casting is then implemented on the FPV object. When the left mouse button is clicked, a ray is sent out. This then accesses the ip address of the node that it targets. A GET request is then made to this ip address. This allows the node that received the GET request to update its database information. The node will then toggle states according to the database.
A “Hello World” example of the LEAP motion plus was also built in Unity3D. This will help us to begin allowing for extra levels of interaction with the environment. The next steps for the system include adding additional functionality to the nodes such as RFID reading. We also hope to upgrade the current 3D images used in the node prefab to make the items look more professional. If time allows, experiments will be done using the leap motion to interact with the nodes themselves.
1/28/2015 – Mesh Visualization Database Development
This week I have developed the database to be a working model of what I am to expect. I have 5 tables currently that will keep records of the transactions between the nodes and the database. There is a table for each type of sensor. This ensures modularity and allows each type of sensor to be added and removed at will.
The first table is current_table. Its purpose is to keep a record of the current meta data of the nodes. It has the columns: node_id, node_status, location, transaction_id, and time_stamp. I have created a “upsert” function which will check whether or not the node_id to be inserted matches any of the records in this table. If it does, then it will replace that record with the new record. The transaction_id gets its value from a sequence object in the database that increments each transaction. Using this transaction_id, I am able to store a history of the node in the other tables.
The sensor tables include the light_sensor_table, rfid_sensor_table, and temperature_sensor_table. These tables stores the history of the sensor data. It is referenced by the transaction_id as a primary key. This allows me to keep a record of all the sensor readings and have a relation between the node and its sensors.
The node_history table keeps track of the meta data of the node. These will also be referenced by the transaction_id as the primary key. Whenever the current_table is updated, the old record will be placed here.
Unity will be responsible for querying the current_table for the nodes that are currently in its field of vision. This will ensure that only nodes that need updating will be updated.
This week more work was done in Unity3D. The functionality is essentially the same, however the implementation has been changed. Before, we were initializing a NodeClass class simply to make a List of this type of data structure. This worked fine for the proof of concept, but as we were trying to expand the functionality, it was apparent that it had limitations. We replaced NodeClass with NodeClassMono which inherits from MonoBehavior. This class was then applied to the prefab so that we can store the relevant data with the gameobject itself.
We also changed the PostgreSQLUtlity to be a monobehavior. The initial plane of the game environment generates the first set of nodes. From there, each node is then able to check to see if its information has changed in the database by comparing its node ID and its Transaction ID. If both match, the node does nothing. Otherwise, it will update to the new information.
Using the methods inherited from Monobehavior, we check to see if a Node is in view. If it is not in view, the node simply sleeps. Once the node is in view, we check every few frames for changes. Checking every frame causes the system to act extremely sluggish as it takes awhile to process the database calls, however, with a second or two of delay the system runs smoothly. As the system develops it may be useful to implement a message queuing system or some other parallel system so that the database calls can happen in the background while the rendering is taking place.
Our next step is to make the nodes physically react to changes to the database. Right now, only the instance variables of the object change. We also hope to add two way communication from within Unity, to the Raspberry Pi.
1/21/2015 – Mesh Visualization Beginning
This week’s focus was on visualizing the mesh using the Unity Game Engine. We began by creating a PostgreSQL database. In order to properly test the system. The PostgreSQL database was run on a separate workstation than the unity game engine. This was so we could ensure the system would be able to work on the mesh network. The scripts we used to setup the database can be found on the github account, however access is currently private while the system is in development.
In our PostGreSql database, we have 5 tables set up. The first table is to keep a record of all the current states of the nodes. Three other tables hold sensor data, which will hold the current sensor values of the nodes as well as keep a record of all the previous sensor data values in the past. These will be ordered by transaction ids. As each node updates the database, the transaction id will be incremented and the resulting sensor data will be placed in the corresponding tables. This will allow an efficient way of looking up sensor history for a node as well as add modularity to the nodes so that we may add and delete sensors easily. We have specified a web server set up so that the nodes will be able to connect to the server and send json formatted data. The web server will handle the database insertion. The data base will handle some logic so that the transactions and time stamps are up to date.
In unity, a quick and dirty program was set up. The required DLL’s that need be to added to the Assets directory in order to interface with the postgresql database are Npgsql.EntityFramework.dll, and Npgsql.dll. Using C#, we read location data from the database, and then placed a prefab cylinder onto a flat plane. After the proof of concept was created, we established some better classes to abstract out the functionality. The NodeClass.cs file has various methods established for storing and interacting with data read in from the server. NodeMap is essentially a dictionary setup to contain the information of every node. It is a key value pair where the key is the node id number, and the value is the NodeClass object. Finally, a PostgreSQL utility was created to read the data from a remote database.
12/17/2014 – Device chatter over mesh
We have tested on the two configurations mentioned on 12/03/2014. Briefly, the first configuration is when no nodes are acting as DHCP servers and relay all requests to the external network of the school. The second configuration is having one or more nodes act as DHCP servers instead. With the second configuration, we were able to have a Raspberry Pi connected to each router and they were able to ping each other through the mesh. With the first configuration, each raspberry Pi was assigned an IP address from the external network and were also able to ping each other through the mesh. We may go ahead and use this configuration since this allows any computer hooked on the school’s network access to the devices on the mesh. We are looking into using RabbitMQ as a service for messaging over the mesh and have successfully enabled a computer on the school’s network to chat with a raspberry Pi on the mesh network. The next steps we are looking at building mesh networks over different frequencies. Hopefully next semester we will be able to start developing applications over the mesh network.
12/10/2014 – Mesh over Bluetooth and Software Programmable Radios
We are going to attempt building the mesh network that is set up on Bluetooth instead of Wifi. Currently, we are waiting on Raspberry Pi’s as well as Bluetooth modules to outfit the Pi’s. Our first step will be to set up the BATMAN adv protocol on the BlueTooth interface. This will be our first step towards using Software Programmable Radios as an interface for the mesh network. We will be on winter break until the January 6th, and will continue our effort on that date.
12/03/2014 – Passing DHCP requests through the internet gateway to the external network
The configuration posted last week was able to function because of a phenomenon known as NAT (Network Address Translation). What this meant is that all requests that were forwarded to the Node acting as the Internet Gateway was translated by the node via the routing table and sent to the external network. This configuration operates on Layer 3 of the OSI Model and is not ideal for our purposes. What we did instead was bridge the eth0, bat0, and wlan0 interfaces and assign a static IP address to the bridge. This is the network configuration and wireless configuration. All nodes will have this configuration but the node that is acting as the internet gateway will have its gateway mode act as a server while the nodes that are not acting as an internet gateway will act in client mode. It is important to note that no nodes have a DHCP server acting on any of the interfaces.
Now, when a device is connected to a node either wirelessly or through ethernet connection, the DHCP request is
- forwarded through the mesh to the internet gateway
- sent through the bridge to the external network
- handled by the external network’s DHCP server
- sent back through the mesh to the device
Now the device is able to achieve internet access through the mesh network. This configuration operates on Layer 2, which is more suitable for our purposes.
What should be noted is that once the network is not connected to an external network, there will be no DHCP server to handle the DHCP requests from any of the devices. Either the devices would have to have statically configured IP addresses, or a separate configuration needs to be used for these situations.
We are leaning towards having a separate configuration that has a DHCP server on each node so that new devices can automatically be served and have access to the mesh.
We are now looking towards Software Programmable Radios which are able to access different frequencies . We would like to use this device as an interface for the mesh so that the mesh would be able to “hop” frequencies. We believe that applications built on top of this type of network would be closer to the State of the Art.
11/26/2014 – Setting up DHCP server on the Internet Gateway for mesh nodes
We were able to configure a mesh node to be a DHCP client and pull in an IP from the internet gateway. The wireless configuration for /etc/config/wireless is this file: wireless-bridge-client-dhcp and the network configuration for /etc/config/network is this file: network-bridge-client-dhcp.
The wireless has two wifi interfaces as well. One interface is acting in AP (Access Point) mode and another is acting in adhoc mode. The interface acting in AP mode refers to the lan0 network interface, and the adhoc mode refers to the mesh network interface found in the network file. I put an extra interface lan0 because lan has a dhcp server running on it as specified in the dhcp file in /etc/config/dhcp. I had it configure the eth0 interface instead so that I am able to connect through ethernet to the router and configure it if need be.
The network file specifies that the wireless interface acting in ap mode will be bridged to the bat0 interface which is the B.A.T.M.A.N adv protocol running on the mesh interface. By bridging these two interfaces together, a wireless device connected to the router as an access point will have access to the mesh network. The bridge of these two interfaces will be itself a dhcp client. Thus, it will make requests to the network for a dhcp server (the internet gateway in our case), pull in an IP and configure its gateway and DNS. That means that when a new device is wireless connected to the wireless access point, it will make a DHCP request that will go through the bridge and be assigned an IP from the internet gateway. The device’s network requests can then be forwarded through the node’s mesh interface, through the mesh network, and arrive at the internet gateway to be served.
Some next steps to take after Thanksgiving break would be to have another wireless interface acting in ap mode but be a dhcp server. Then wireless devices connected to the router on that interface would be able to receive IP addresses from the router itself than having to going through to the internet gateway. The wireless devices can then act as leaf nodes which can be used in an application setting. Another hurdle that we need to overcome is having these leaf nodes that are connected to different routers able to convey information to each other upon request. This requires each node to be aware of the other nodes’ existences. Hopefully we can utilize the broadcast IP address for this effect. We won’t know until we’ve eaten some turkey though. Have a great thanksgiving. It’s also my birthday today.
11/19/2014 – Accessing the external network using NAT
After an arduous ordeal, we were able to connect a node to an external network through its ethernet port acting as a DHCP client. We were also able to bridge the wifi and its mesh interface together so that the node is able to interact with the members of the mesh. Our goal was to have members of the mesh network use this node as a gateway to the internet. We had the Raspberry Pi act as an endpoint of the mesh and we would like to be able to ping the ip address of 188.8.131.52 which is a DNS of google.
Node Superman will act as the Gateway to the internet for the nodes on the mesh network. This is the configuration of the wireless-bridge file found in /etc/config/wireless. In this file, we make two different interfaces for the wireless device. The first interface is in Access Point (AP) mode which broadcasts to devices through a standard wireless network that we all know and love. The second interface is used in ad-hoc mode which is used for interacting with the mesh network. So we have the wireless device acting as both a wireless access point as well as a mesh access point. Now, we must configure the network file to match these wireless interfaces.
This is the configuration for the network-bridge file found in the /etc/config/network. The AP interface in the wireless is referenced to the ‘lan’ interface of the network file and the ad-hoc mode interface is referenced to the ‘mesh’ interface of the network file. In the ‘lan’ interface, we have the wireless device in AP mode bridging with the bat0 interface (bat0 is created when mesh is running the batman-adv protocol). Note: There is no bridge created between the AP mode with the ethernet. We do not want this because the B.A.T.M.A.N adv nodes will flood the ethernet with packets that are encapsulated with its custom headers and the network is not able to understand these packets (this caused problems with eth0’s request as a DHCP client). Now, eth0 is acting as a dhcp client and so it pulls an IP and gateway from the dhcp server that is in the external network. Thus, this node has a default gateway that requests to external IP’s will go through. Therefore, all the requests coming in from the mesh network will be handled by this node and sent out through the ethernet interface and responses will be forwarded to the respective nodes.
We were able to ping Google’s DNS through a Raspberry Pi that was connected to another bridged Node called Joker. The wireless configuration is the same as the above. The network interface is a bit different and is found network-bridge-client. The Raspberry Pi is running a DHCP client on its ethernet interface and so it will pull an IP from Joker since Joker’s eth interface is acting as a DHCP server. Joker has its wireless device bridged to the ethernet interface as well as the mesh interface. We needed to manually set the default gateway of Joker to be the IP of Superman, which can be accessed through the mesh interface from the bridge. So, requests from the Joker’s ethernet will be forwarded through to the mesh interface and find its way to its destination. Our request for 184.108.40.206 from the Pi was forwarded through the mesh interface and picked up by Superman which handles it and provides the PI with the intended response.
This leaves us in a place where we have to have two configurations. One configuration for a server and one configuration for a client. We are going to look at this site to see if the internet gateway can broadcast itself so that new nodes can join the mesh and automatically configure itself so that its default gateway matches the ip of the internet gateway node.
11/12/2014 – Adding routers and devices to the mesh
We were able to add two more Routers running B.A.T.M.A.N adv to the mesh and have them act as interfaces to the mesh. We accomplished this by bridging the wlan0 interface which has the B.A.T.M.A.N adv protocol running on it and its ethernet interface. With this configuration, we are able to attach a device to the ethernet of the bridged router and the device would gain access to the mesh. We have one Raspberry pi that is acting as a web server that is connected to one of the bridged routers. We also have one router acting as a wireless access point to the mesh which is connected directly to a bridged router that is part of the mesh. This setup allows us to pull up the Raspberry Pi’s web page on any device connected to the wireless access point.
11/05/2014 – Installing B.A.T.M.A.N adv on Tl-MR3030 Router
We finally were able to install B.A.T.M.A.N adv on the router TL-MR3040. We accomplished this by:
- Flashing a snapshot of OpenWRT onto the router through a firmware upgrade
- Configure the /etc/config/network file and /etc/config/wireless file so that the ethernet interface becomes a DHCP client while the wlan0 interface has a static IP address. This will be used for the router to connect to the internet while allowing us to SSH into the router. Afterwards, make a backup file of these files so that you can quickly switch between files. We used these files for network-bkup wireless-bkup To understand the configuration for these files look at network and wireless. Make sure to reload the network with /etc/init.d/network reload for the changes to take effect
- Once the router has internet connection, we need to run the following commands:
- opkg update
- opkg install kmod-batman-adv
- opkg install batctl
- If there is an error detailing a kernel incompatibility, then you need to reflash the router with the current snapshot. The snapshots are nightly builds so they quickly become obsolete. Instructions for upgrading are here
- Now configure the /etc/config/network file and the /etc/config/wireless file for B.A.T.M.A.N. We used these files: wireless network
- Once the network is reloaded, you should see the wireless interface when you run the command ifconfig. Add the interface to batman using batctl following these commands.
- The ssid of the mesh network should show up on your laptop if the steps are done correctly and you should be able to ping the other routers with the static ip set up for the bat0 interface on the network