Blockchain & IoT based solar panel maintenance @ Hack The Valley

Foo Baar: Hack the Valley.

Is there a better place than the crypto valley for a blockchain hackathon? Thomson Reuters hosted the second edition of its hacking challenge in Zug, Switzerland on  27-29 January 2017. This promising event was sponsored by EY Switzerland and a team from EY Paris Experience Lab flew over to Baar. This is what happened:

The hackathon consisted of three challenges:

       Exploring the intersection of blockchain and IoT

       Fighting fraud in the supply chain

       General applications

Julien Marchand, Nicolas Maurice and I (Jérôme de Tychey) were interested by the first one and we connected with my friend Thibaut Schaeffer from the start-up Provenance. We brainstormed about the IoT applications and decided to order a drone to play around. A quick survey of available SDK and price benchmarking led us to a Bebop 2 by Parrot that arrived just on time. A colleague lent us a backup Bebop 1 just in case. We packed everything for a Paris-Zurich flight with 2 drones, 6 laptops and 2 raspberry pi hence the awkward security checks at the airports.

First surprise at the registration desk: many gifts, very filled tote bag!

doge-such-gift-much-wow

Among the goodies we received a cool Ether Cards. It shows an address and the mnemonic under a scratch field. This address was associated with a proof of attendance token like the Devcon 2 token by Pipermerriam. The contract is deployed on the main net. As you can see, my balance is 1:

proof-of-att

Thomson Reuters also issued a special pint glass with the hackathon’s logo on it:

image0000001

And this edition’s t-shirt was red (see London’s green for comparison):

Thomson Reuteurs had set up an Ethereum testnet for the weekend named Norsborg. For the record, Line T13 of Stockholm subway goes from Ropsten to Norsborg, the first is the codename of the public Ethereum testnet.

Our challenge: exploring the intersection of the blockchain and IoT

The hackathon began with the usual presentation of the sponsors and tools available followed by a networking cocktail. A second surprise came along at this point, two colleagues from EY Paris FSO were looking for a team. Pierre Chemla and Jonathan Slomka joined us and the Foo Baar team was formed:

After brainstorming, we defined this IoT scheme for solar panel maintenance:

       A solar panel linked to a connected meter that runs an Ethereum node

       A smartcontract to request a drone inspection

       A ground control station for the drone, also running an Ethereum node

Blockchain idea F.A.Q.

       How relevant is IoT there?

In the absence of permanent maintenance, a solar panel RoI can be divided by 3. Our solution brings automatic inspection when the output drops (e.g. when the panel is too dirty or has a crack). This approach is serverless, the IoTs only interact online with the blockchain thus hardening the protection against say Man in the Middle attack for example.

       Do we need a blockchain for that?

The blockchain brings protections against attacks and a built-in payment system. It allows for secure interactions, public deterministic execution and auditability.

       What does it do?

A smartcontract handles the requests for inspection by firstly checking if the drone is not already in flight, secondly checking if the address asking for the inspection is permissioned to do so, and thirdly checking if the weather conditions are OK. This last step involves a call to an API for the wind speed provided by Oraclize. After validating all the checks the smartcontract updates a variable indicating that the drone is now in flight and releases an event that will trigger a reaction from the ground control.

The Ground control loads a flight plan corresponding to the Ethereum address that made the request for inspection, i.e. the meter of the malfunctioning solar panel. The drone has a mission to take a picture of the solar panel and come back for the Ground control to upload the picture and to reset the state of the smartcontract. The picture is uploaded on IPFS in order to stay on decentralized blockchain-friendly protocols. Since we are collecting pictures of malfunctioning solar panels we also set up a neural network to recognize the condition or the solar panel. This feature allows for further developments such as passing the cleaning or repairing duty to another IoT or in a bounty smartcontract.

This video of our presentation sums it up:

Under the (Ethereum) hood:

The whole project is open sourced here. Let’s look at the inspection cycle:

       This transaction requests an inspection, the first and second conditions are met in the current state of the blockchain, i.e. the drone is not in flight and the address is authorized.  A verification of the weather conditions by Oraclize is therefore triggered, see the event logs:

tx-request-for-flight

       At this transaction Oraclize makes a callback with the wind speed

oraclize-call-back-event

       The 6.55 km/h in the input data is low enough for a drone to fly (trivia: see Beaufort scale)  so the mission is accepted as shown in the event logs:

windspeed

       At this point the drone is loaded with the proper flight plan and takes a picture during flight. When it comes back the picture is passed to the ground control station to upload it on IPFS.

       This transaction from the ground control station resets the state of the drone so requesting a flight is possible again, it also contains the IPFS multihash of the picture (starting with “Qm”) that is logged in the events so everybody can have a look:

ipfs-mult

IoT: from zero to hero?

We simulated the meter straightforwardly but creating flight plans and having the Bebop 2 follow them was unexpectedly complicated even with the node.js library node-bebop.

Initially we wanted to use the SDK ROS but it was both to long to install and too hard to use for a hackathon. Node-bebop was easier even if the master branch was not compliant with the current firmware of our Bebop 2, we therefore used the firmware-4.0 branch.

We expected the drone to be more stable in flight, let’s just say that it is certainly not designed to be used indoors. Collecting the picture that was taken was also difficult, we relied on a second connection to the drone, FTP based, to get it that were unpredictable to say the least.

The internal clock of the clock often reseted itself to the year 1970 for no apparent reason which led us to permanently clean off the pictures. The API to change the drone’s clock wasn’t working and the timestamping of the pictures was also hazardous even when the clock looked good. The textual naming, containing the time, was usually good but sometimes did not match with the time in the metadata. Lastly, one should always properly screw the helix of a drone…

Adding machine learning to the list

Since the scheme allows for the constitution of a solar panel picture database it sounded interesting to feature the recognition of the dirtiness. Being able to tell if the solar panel is dirty or damaged would lead to publishing bounty smart-contracts to fix the problem.

team-ey

We spent three hours compiling the library openCV and played with facial recognition :

Conclusion:

The event was quite fun and well organized, we are now looking forward to do more blockchain IoT integration.

 

Bonus: Roland Kofler’s experience at the hackathon

Jérôme de Tychey