Group Actions
Engagement
  • Author Author: aspork42
  • Date Created: Date Created
  • Views 3556 views
  • Likes 18 likes
  • Comments 18 comments
Related
Recommended

Anyone up for an IIOT Relay Race? (Ignoble Internet of Things)

aspork42

My wife and I were talking about the E14 site and she asked something about doing a team project. It was a very interesting idea, but most likely we all have enough of that in our day jobs. I still liked the idea of having to work out design details and specs as part of a design challenge with people from literally all across the globe. I mulled the idea over and over and this is what I have come up with.

 

The concept is as follows:

 

Each participant must create some soft of IoT enabled device. (Not too bad, right?)

 

The device must do three things:

  1. Get some sort of input from the World Wide Internet
  2. Do something
  3. Post something else back out to the World Wide Internet.

 

Sounds pretty simple, huh?

There's a catch - this is a "relay race". That means that when Participant "A" posts something, that is the trigger for Participant B's project - which is armed and waiting for A's post. Once "B" is complete, that will trigger Participant C's project. This means that there will be an input and an output for each person that must be sequenced.

 

For Step 2, "Do something", It could be simple or complicated. It could be as basic as turning on an LED on an Arduino, display something on an LCD, calculate Pi to 'x' places, or complicated like having a MeArm waiting to manually peck at a keyboard to post something on Twitter. You could have your model train turn on and start driving until it breaks a light beam to trigger the output.

image

 

For the web interconnects, we can get creative here as well. Twitter works pretty well, but we could also use a public MQTT server (Mosquito), parse an email, or send via RF/Ham/ Morse Code / semaphore if you are close enough (and licensed) to another participant. Any API for any platform that two users are able to work together on. Users could apply in groups for highly specific interconnects, and we could have the E14 team assign the rest of the order.

 

The format would be pretty wide open - each participant will agree with their two "co-workers" on the exact interconnect methods. The Input and the Output method could be different for any given project, depending on the users (i.e. read from Twitter, then send an email when done). The project could be as simple or as complicated as the user is able to do in the allotted time. I'm thinking 30-60 day project).

 

One challenge would be the exact timing (time of day/elapsed duration) of the final run - we are a global community from all corners of the earth, so some people would have be up at late hours to record the event. Ideally each unit would complete its task in less than 1 minute (or really a few seconds for simple things), but perhaps we could build in time gaps... i.e. if you have hacked your washing machine, it would start running when it gets the trigger, and when the clothes are done some 35 minutes later, it would trigger the next person. That way, we could build in some delays.

 

So this would end up a world-wide Rube-Goldberg, but we would call it "The Ignoble Internet of Things Relay Race"

 

This made me think back to this post, but now imagine each Arduino is 1000 miles apart!

Celebrating Arduino with a Torch Relay!

 

During the final run, everyone could record a video and we could edit them all together.

 

Since "success" is defined by the entire project going from start to finish, there would't necessarily be a winner, but we could vote on most creative and try to con into making up some T-Shirts.

 

Post your comments - What would some unique interconnect methods to talk to devices which are far apart? What would your project do before sending a response?

Parents

  • It looks like 1960's teletype potentially been added to the list of communications methods Slight smile

    /challenges-projects/element14-presents/project-videos/w/documents/27567/episode-546-mapping-the-outputs-of-a-1960s-teletype-machine---how-hard-can-it-be?CommentId=0e4e2102-c08d-4751-a177-d887ddc70986

    It would be quite interesting and fun to take parts of the relay off-Internet however it could also potentially cause some issues. If too much of it is off the Internet then you perhaps start to lose the ability to track the activity throughout the duration of the event and there is no sure way of knowing if it is still going on off-Internet just very slowly or if it has failed. It also becomes less of a 'spectator event' if viewers aren't getting regular updates.

    A peer-to-peer format relay is probably more true to the spirit of things however it does have a significant issue in what happens if any one node fails. In a true event that would be relay race over, which isn't much fun for all those participants waiting for their turn. Related to this is how does each participating node know who to contact next and what happens if that node has to pull out at short notice or reschedule their slot with minimal administration overhead, given the issue of time zones etc. This could result in an unsuccessful attempt at completing the relay.

    Starting out, it may be that by having a high availability node coordinating the relay race may help keep it going by having each participating node providing activity status (ready / active / complete) and then the relay race coordinator node assigning the next node which is reporting a ready status. If a node doesn't complete within a given agreed timeout period then the coordinator node moves things onto the next participating node showing a ready status. If a queued participating node becomes inactive whilst waiting then it is skipped over but still gets another chance if it becomes active again. Every participating node gets a chance. The co-ordinator node could also take care of automatically posting regular status updates as the relay race progresses. The longest chain of successful consecutive nodes then becomes the target to beat the next time round. In order to keep things running though some nodes could perhaps be designed to be re-triggerable, so if the active node queue runs out, then those nodes will run again giving time for new nodes to join in. This may help with time-zone related issues.   

    With off-Internet sections, then the gateway nodes could perhaps declare this with the coordinator node which then allows for a longer timeout period and specifies the second gateway node to acknowledge complete status from. There however would be a lack of automated status updates during this period and if prolonged, would rely on those participants to post any comments about the activity to keep interest. You could also consider domino train type races where multiple nodes could be triggered to run simultaneously which would allow for really slow nodes to participate as well.

    What is actually getting relayed needs some thought. If it is a text message then the maximum size of the message will need to be declared as a participant could potentially be limited physically (e.g. if they are loading scrabble tiles into a fixed number of individual train wagons for them to be scanned by OCR at the destination station), or some people may want to display it on a small display (imagine a micro:bit trying to scroll 1,000 words one character at a time). If it is a teletype, there may be a limited character set and as this is a global community then their may be language considerations as well. It could be that the participating node specifies its message capability with the coordinator node when registering as a participant and then gets passed an appropriate version of the message when its turn comes up. Participant nodes just wanting to turn on LEDs wouldn't need to be passed a message (or they could perhaps be given a word count value instead). Messages could potentially also be extended to other formats as well. It depends if this is to be more of a message type relay race or more of a Rube Goldberg Machine. 

    Another consideration is how do you broadcast / document the event effectively both as it takes place and afterwards. 500 participants turning on a LED and the whole event could be over in a matter of seconds, whereas 18 participants each taking 10minutes and you are looking at 3 hours. The idea of the telephone game is perhaps more suited to those following on-line as each node is outputting content, but perhaps a bit uneventful as digital technology will likely do a pretty good job at copying data accurately between nodes. The Rube Goldberg Machine concept is a lot of fun but is more difficult to capture remote nodes on-line in real time so relies on the uploading of videos and photos or live streaming.

Comment

  • It looks like 1960's teletype potentially been added to the list of communications methods Slight smile

    /challenges-projects/element14-presents/project-videos/w/documents/27567/episode-546-mapping-the-outputs-of-a-1960s-teletype-machine---how-hard-can-it-be?CommentId=0e4e2102-c08d-4751-a177-d887ddc70986

    It would be quite interesting and fun to take parts of the relay off-Internet however it could also potentially cause some issues. If too much of it is off the Internet then you perhaps start to lose the ability to track the activity throughout the duration of the event and there is no sure way of knowing if it is still going on off-Internet just very slowly or if it has failed. It also becomes less of a 'spectator event' if viewers aren't getting regular updates.

    A peer-to-peer format relay is probably more true to the spirit of things however it does have a significant issue in what happens if any one node fails. In a true event that would be relay race over, which isn't much fun for all those participants waiting for their turn. Related to this is how does each participating node know who to contact next and what happens if that node has to pull out at short notice or reschedule their slot with minimal administration overhead, given the issue of time zones etc. This could result in an unsuccessful attempt at completing the relay.

    Starting out, it may be that by having a high availability node coordinating the relay race may help keep it going by having each participating node providing activity status (ready / active / complete) and then the relay race coordinator node assigning the next node which is reporting a ready status. If a node doesn't complete within a given agreed timeout period then the coordinator node moves things onto the next participating node showing a ready status. If a queued participating node becomes inactive whilst waiting then it is skipped over but still gets another chance if it becomes active again. Every participating node gets a chance. The co-ordinator node could also take care of automatically posting regular status updates as the relay race progresses. The longest chain of successful consecutive nodes then becomes the target to beat the next time round. In order to keep things running though some nodes could perhaps be designed to be re-triggerable, so if the active node queue runs out, then those nodes will run again giving time for new nodes to join in. This may help with time-zone related issues.   

    With off-Internet sections, then the gateway nodes could perhaps declare this with the coordinator node which then allows for a longer timeout period and specifies the second gateway node to acknowledge complete status from. There however would be a lack of automated status updates during this period and if prolonged, would rely on those participants to post any comments about the activity to keep interest. You could also consider domino train type races where multiple nodes could be triggered to run simultaneously which would allow for really slow nodes to participate as well.

    What is actually getting relayed needs some thought. If it is a text message then the maximum size of the message will need to be declared as a participant could potentially be limited physically (e.g. if they are loading scrabble tiles into a fixed number of individual train wagons for them to be scanned by OCR at the destination station), or some people may want to display it on a small display (imagine a micro:bit trying to scroll 1,000 words one character at a time). If it is a teletype, there may be a limited character set and as this is a global community then their may be language considerations as well. It could be that the participating node specifies its message capability with the coordinator node when registering as a participant and then gets passed an appropriate version of the message when its turn comes up. Participant nodes just wanting to turn on LEDs wouldn't need to be passed a message (or they could perhaps be given a word count value instead). Messages could potentially also be extended to other formats as well. It depends if this is to be more of a message type relay race or more of a Rube Goldberg Machine. 

    Another consideration is how do you broadcast / document the event effectively both as it takes place and afterwards. 500 participants turning on a LED and the whole event could be over in a matter of seconds, whereas 18 participants each taking 10minutes and you are looking at 3 hours. The idea of the telephone game is perhaps more suited to those following on-line as each node is outputting content, but perhaps a bit uneventful as digital technology will likely do a pretty good job at copying data accurately between nodes. The Rube Goldberg Machine concept is a lot of fun but is more difficult to capture remote nodes on-line in real time so relies on the uploading of videos and photos or live streaming.

Children
No Data