PolyMap: Leveraging Godot for Visualization (#3)

 

Leveraging Godot for PolyMap Visualization

Introduction to PolyMap and Visualization Goals
PolyMap is my experimental platform exploring multi-agent, robotic swarm-based Simultaneous Localization and Mapping (SLAM) strategies for mapping real-world environments. Development has been incremental: starting with a simulation, robot agents, a mapping manager, and basic visualization. One key goal was to leverage existing technologies like game engines to rapidly create an operable system. Game engines also offer a natural interface to visualize the spatial data generated by the robots as they explore physical space—and it’s just really cool!

---

Why Godot?

Why use a game engine instead of existing tools like RViz? There’s no single answer. RViz and others are developed for the ROS environment and are reportedly easy to integrate with ROS, but I haven’t explored ROS yet. Possibly due to hardware constraints or concerns about getting locked into a specific architecture, I’ve chosen instead to learn the fundamentals of the (robot) science before adopting fully developed solutions. This is also exactly why I’m starting with a single ultrasonic sensor rather than a Lidar for spatial sensing. There is a vast amount of unbuilt software needed in this space, and I want to understand the basics before being embedded in one ecosystem. (A related question: is ROS becoming a walled garden?)

I chose Godot because it’s open source, has no license fees, and has a large community. It can render immersive 3D environments with advanced graphics and interactivity—features that would take far longer to build from scratch. This makes enhancements like zooming, panning, robot tracking, and detailed exploration straightforward. Overall, it’s a friendly platform for any maker stepping into games or 3D visualization. Plus, Thor from Pirate Software thinks "Godot is the Blender of game engines". 😉

---

Transitioning from Python to Godot
The original Python-based visualization tool was a solid proof-of-concept for displaying the global map and robot telemetry. As the project matured, I planned to try a game engine to overcome Python’s limitations in interactivity and feature expansion—where everything had to be built from scratch. 

Transitioning to Godot 4.4 opened new possibilities for a more fluid UI. Because PolyMap uses MQTT for distributed communication, multiple visualization clients can consume the same data. This architecture also means each component can be developed in the best language for its function: the simulation and map manager will stay in Python, while the robot agent code (currently Python) will move to C++ for real hardware deployment. 🤖

Here is a video showing the transition and new version:

---

Integrating MQTT Communications in Godot
A critical aspect of PolyMap is using MQTT for data exchange. Fortunately, people like Goatchurch paved the way by porting MQTT code into Godot. It was showcased at a Godot convention, and most importantly, their open-source work on GitHub allowed me to clone it. Within a short time, messages from my existing Python version appeared in Godot. Once the MQTT connections and message handling were in place, communications were solid, letting me focus on features and functionality.

In the prototype, there’s a connectivity dialog box where the user enters the server URL, port, user ID, and password. It also allows topic subscriptions and message publishing. In this setup, the visualization subscribes to global_map and telemetry topics. Currently, the entire 100×100 integer map is broadcast every second, alongside telemetry data from the robot agents.

---

Using Godot
One of the most exciting aspects of Godot is how easily you can configure screens and add new features. Godot is heavily object-oriented; everything is a Node with attributes and methods. It reminds me of early “thick client” GUI development (pre-Web, like Acius 4D). This is my first Godot project, so I’m still learning and deciding how much to configure in the editor versus coding in scripts. Right now, screen elements are configured in the editor, while global map rendering is done in code.

There is a learning curve to working with Godot, but I understand it is very similar to other game engines like Unity and Unreal engines. For me, it was natural to code with an AI (or two, or three) to help me quickly learn how Godot works. There are also good videos on YouTube as well such as this video. One issue I ran into was that many of the AIs did not know how Godot 4.4 had changed from earlier versions, there was a constant effort required to correct the AI when it was off hallucinating. 🙂

Building the first prototype had its challenges: positioning the camera to view the map, deciding where to place MQTT functions, and balancing performance between rendering each grid point individually or using a grid mesh. Once I got the hang of Godot, it was surprisingly simple to get the visualization working. Adding a mouse-wheel zoom took only five minutes. I’m excited to add more capabilities quickly!

---

Future Features
With the first iteration working, here’s what I’m planning next:

• Persistent Map: I can choose between redrawing the global map each time, or making it more persistent and only updating changed elements as the are discovered by the robot.
• Free Fly - Camera: I will change the primary camera and give the user the ability to 'free fly' over the map moving around the landscape discovered by the robots. 
• Robot FPV: It should be possible to put a camera in each of the virtual robots, allowing the user to select the robot and view the 3D space from its perspective.

Looking ahead, I’m breaking out the map manager and robot agent code from the simulation, moving toward a distributed computing platform. This is a key step for migrating from simulation to real hardware. Stay tuned for more updates!

A Robotic Platform for Remote Exploration

A Robotic Platform for Remote Exploration, Sensing, and Monitoring

Earth Exploring robot concept that is "Totally" Not Evil!

Me and another Robot (LLM), design a robot for earth exploring!

let's design a robot platform for remote exploration, sensing, and monitoring.  What components would it need?

Designing a robot for remote exploration, sensing, and monitoring involves a combination of hardware and software components, each tailored to the specific requirements of the environment it will operate in and the tasks it will perform. Here's a detailed breakdown:

Hardware Components

1. Mobility System: 

   - Type: Depends on the terrain. Wheeled or tracked systems for ground, propellers for aerial, or thrusters for underwater exploration.

   - Material: Durable and lightweight, like carbon fiber or reinforced plastics.

[x] let us consider going for a rocky, sandy terrain with some vegetation, should be able to climb up a moderate slope.

2. Power Source:

   - Options: Solar panels, rechargeable batteries, or fuel cells.

   - Consideration: Longevity and environmental impact.

[x] electric and rechargeable, certainly. perhaps with multiple ports, incase someone wants to share a few watts of power.

3. Sensors:

   - Environmental Sensors: Temperature, humidity, atmospheric pressure.

   - Navigation Sensors: GPS, IMU (Inertial Measurement Units), lidar, sonar.

   - Specialized Sensors: Chemical sensors, radiation detectors, biological sensors.

[x] leave lots of room for sensors, that is what this is all about.

4. Communication System:

   - Options: Satellite communication for remote areas, Wi-Fi or Bluetooth for urban environments.

   - Redundancy: Essential to ensure constant communication.

[x] multiple options, use them all. perhaps even piggybacking on someone's iphone like an airtag?

5. Data Storage and Processing Unit:

   - Type: Onboard computer with robust processing capabilities.

   - Requirement: Must handle large amounts of data from sensors.

[x] bigger the better. just put it in a safe environment.

6. Robotic Arm or Manipulator: (why not?)

   - Capabilities: Picking, sampling, or minor manipulation tasks.

   - Design: Lightweight and flexible.

[x] absolute!  what is a robot without a manipulator or two, three...

7. Protective Casing:

   - Purpose: Protect against environmental conditions like temperature extremes, water, dust, etc.

   - Material: Dependent on the environment (e.g., waterproof materials for underwater robots).

[x] this will be extreme use them all.

8. Camera System:

   - Types: High-resolution visual, infrared for night vision, possibly 3D cameras.

[x] need cameras, many! we are all watchers for where this robot can go.

9. Emergency Systems:

   - Components: Emergency shut-off, self-diagnostic capabilities, fault-tolerant design.

[x] this robot is on its own, it will need to be self-reliant. not sure on the shut-off though?

Software Components

1. Operating System:

   - Type: Real-time operating system for immediate response to sensor inputs.

[x] both OS and controller, ROS2 is a good start, with subcomponents and watchdogs on controller circuits.

2. Navigation and Mapping Software:

   - Function: Path planning, obstacle avoidance, and real-time map generation.

[x] SLAM! Bam, thankyou mam!

3. Data Analysis Software:

   - Purpose: Process sensor data to extract meaningful information.

[x] let us do some on site, and send the rest to the mothership.

4. Communication Protocol:

   - Design: Secure and reliable, able to handle varying signal strengths.

[x] assume sparse and periodic communications, this is reality really.

5. AI and Machine Learning Algorithms:

   - Application: Autonomous decision making, pattern recognition, predictive maintenance.

[x] the fun part!

6. User Interface:

   - Features: Remote control capabilities, data visualization tools, alerts and notifications system.

[x] all of the above. lets give it some on-board UI, as well as the remote operations.

Additional Considerations

- Modularity: Designing the robot with interchangeable parts can enhance versatility and ease of maintenance.

[x] done!

- Scalability: The design should allow for easy updates and integration of new technologies.

[x] absolute

- Sustainability: Consider the environmental impact of the robot during its lifecycle.

[x] be kind to earth.

- Legal and Ethical Compliance: Ensure compliance with regulations in areas of operation, especially for data handling and privacy.

[x] don't hurt Hooomans!  after all it must be TOTALLY Not Evil!

- Safety Features: Crucial if the robot operates in public spaces or near humans.

[x] hey, don't hurt the meatbags!

Speculative Technologies

- Swarm Intelligence: For tasks that require large-scale monitoring, using a group of smaller robots working in a coordinated fashion.

[x] oh yeah! Robots that have robots!

- Advanced AI: For autonomous decision-making in unpredictable environments.

[o] so easy to say, what does this even mean anymore?

- Wireless Power Transfer: To recharge without physical connectors, enhancing the robot's autonomy.

[x] or better yet, lets harvest it from 'sources'

I think it would need to look friendly so that it is not abused by Hooomans that find it. 

Absolutely, the robot's appearance plays a crucial role in how it's perceived and treated by the public, especially if it's operating in areas where it might encounter people. A friendly, non-threatening design can help to mitigate the risk of abuse or vandalism. Here are some design aspects to consider for a friendly appearance:

Design Elements for a Friendly Appearance

1. Color Scheme:

   - Selection: Choose soft, approachable colors. Pastels or bright, non-intimidating colors like light blue, green, or yellow can convey friendliness.

   - Purpose: Avoid aggressive or military-like colors that might be perceived as threatening.

[x] lets go with broad Pink and White stripes.

2. Shape and Form:

   - Design: Rounded edges and smooth contours are generally seen as more friendly and less aggressive than sharp angles and points.

   - Inspiration: Take cues from popular consumer electronics or characters in family-friendly media that are known for their approachable designs.

[x] Animals have rounded edges too.

3. Size and Scale:

   - Proportion: Not too large to be intimidating, but not so small as to be easily tampered with. A medium-sized build can be optimal.

   - Aspect: Humanoid or animal-like features can be engaging and relatable.

[x] medium is good.

4. Facial Features or Equivalent:

   - Display: If applicable, incorporate a simple, digital face or emotive lights. Expressions like a smile or blinking lights can create a sense of friendliness and approachability.

   - Interaction: Features that react to human presence (like turning towards someone when they speak) can foster a sense of interaction.

[x] true! maybe with a goofy grin on it.

5. Sound and Voice:

   - Tone: A friendly, non-threatening voice for any audio communication.

   - Sound Effects: Gentle, pleasant beeps or musical tones instead of harsh or alarming sounds.

[x] beep bop! Hello!   -- thanks R2D2!

6. Branding and Signage:

   - Labels: Clear, friendly branding with logos or mascots that suggest helpfulness and positivity.

   - Information: Displaying its purpose (“Research Robot”, “Environmental Monitoring”, etc.) can help people understand its presence and mission.

[x] should clearly state that it is "TOTALLY Not Evil!"

Desert Robot Project

 

Sonoran Desert - Arizona, USA

My new objective for remote robot exploration in collaboration with Patterntology

Exploring Robots:  Desert Robot Project

Living in the desert, watching what is going on around. An Internet <=> Reality interface/portal. It is a true remote sensing platform that is self-sustaining. It needs protection from the harsh elements of sun, rain, dust, and animals. It has to have the right scale to move and manipulate. but most of all it has to have the ability to see and sense and to communicate this back to the digital world.

This post is a collection of thoughts on what a Desert Robot could potentially be.

Functionally:

It will be a remote sensing platform, with the ability to move, manipulate, and communicate. This is the basic function of all of the probs we have sent to planets, asteroids, and space. But, these robot will be for earth.

It is clear that all Exploring Robots will have the common requirements of:

• Sense the Environment (vision,hear, temp, smell, feel, etc)
• Manipulate the environment (possibly)
• Move (preferably)
• Communicate its finding, take commands
• Process the above, as well as manage itself
• Power: preferably renewable and storable, and portable

finally, all of the other requirements are all about surviving in the environment they are destined for.

Non-Functional:

outside of the primary functions, the non-functional requirement is to survive. It needs to survive the punishing environment that is not particularly kind to electro-mechanical systems.

Desert Robot surviving means managing these aspects:

• Intense Sunlight, Ultraviolet and Infrared Radiation
• Heat in excess of 45c, or below freezing
• Dust and Sand
• Rain, monsoon flooding, potential immersion
• Desert animals - PackRats!  Insects and critters
• People - that want to abscond with our dear robot

Form:

Shape - the robot could perhaps be some robotic cross between a tortoise and a crab. It would need a hard outer shell for protection and to encapsulate the internal electronics. The bottom would need to be smooth, like a tortoise so that it could slide over rocks and obstacles. A bio-inspired outer shell would be ideal for protecting the primary components.

Mobility - choices on types of movement would need to be adjusted by how far and over what terrain is planned. For the first iterations, I am considering that the robot should be able to move and manipulate, but that it would not travel over long distances. Being constrained to just a few dozen of square meters would allow the focus to be on desert wildlife instead of unexplored terrain or vistas. If this is the case, it would be possible to use some small legs that could drag the robot, instead of wheels or treads. small, stout legs can be implemented with a few simple servos and would not require a large power source.

Scale - how large should this robot be?  That would be a function of the energy budget available and what obstacles it would need to overcome.  On the desert floor in the Sonoran Desert, for example, there are many branches from plants and cactus that would need to be maneuvered around.  The size of the solar panels needed for operations and communications would also need to be considered.

What other design considerations should be made for a Desert Robot?

Please leave your thoughts and questions in the comments section below.

Wild Weasel - Tracked Robot (#3)

I have just posted a YouTube Video of the assembly of the Wild Weasel track.  You can find it here:

Wild Weasel a completely 3D printed Tracked Robot.  I wanted to build a tracked robot, due to their stability, and at the same time use some motors that I had recovered from recycled printers.

The project went very smoothly, a lot of CAD work was need to design the treads, chassis, and gears used.  The robot uses a Raspberry Pi and an L298N motor driver. This was my first time to use a Tallent Cell power bank, which provides 12V and 5V power - great for RPI and the motors.

Wild Weasel - tracked robot (#2)

The first build of the Wild Weasel tracked robot seems to be working well.

Wild Weasel Tracks - in Robot configuration

Here is a video from back in early build, where I first tested out the track.  The track is using two white gears that are from the recycled printer. I went on to recreate these and printing a duplicate set for the second track.  This involved counting the teeth and height and angle of the gears.  Here is a video from my YouTube channel:

As you can see from the video, it is very energetic with 12v of "shore" (mains plug) power. It was running all around my desk, especially as it had no frame besides for the track unit itself - as designed!! ;)

I have since added the Chassis frame consisting of modular units:  a battery bay, a controller bay, and the initial sensor platform.  The robot is fitted out with a tallent cell 12v/5v battery, Raspberry Pi, L298N motor driver, Logitech 920C camera, and USB speakers.

If you would like to drive the robot remotely...  !!  go to LetsRobot.tv and it might be available.  I try to put it online using my TotallyNotEvilRobotArmy stream on LetsRobot.tv.  You can find it here:  TNE-RobotArmy WildWeasel

LetsRobot.tv controls for Wild Weasel (type in chat to speak

Ready to go!

Wild Weasel in LetsRobot Configuration (with lance!)

Learnings and Next Steps:

After some time spent with users operating the Wild Weasel on LetsRobot.tv, there are some learnings. LR is a great way to test out design, the robot gets a lot of (sometimes hard) use.  

• My clever design for locking the module connections does not work.  the 3D printed pin and loops shear off under force. a better solution is to use metal nails perhaps.
• One of the motor stalls much earlier than the other. This may be due to low power from the battery. I will test this further.  The impact is that the robot will not drive straight
• The MQTT client is reading duplicate values sent from the streaming site. I will update the code to ignore long strings of the same command.
• Need a better override at the MQTT level. perhaps a second command channel that will allow me to flush the stream from the other channels.

Anti-Collision detection
Most important, I will be adding an Anti-collision code to the motor controller. I will be using an HC-SR04 ultrasonic distance sensor to determine if the robot is against a wall or other object. I believe the best interface will be just to ignore commands that would try to continue to drive into the obstacle.  more details on this to come.

Wild Weasel - tracked robot (#1)

I have an interest in building and designing out a tracked robot... for some reason. :)  

Tracked robots have static stability, and typically should not get 'stuck' on terrain the way wheeled robots do. Also, you can build, drive, and steer a tracked robot with only 2 motors. The downside of the design is that to turn, they have to 'skid' or slide.

I wanted to design a track system that will be modular and can be combined with other tracks and platforms to easily create new robots. I really like the modular designs of the Intukun pipe inspectors robots. Their mini-track crawler is an impressive piece of crawling hardware. Of course, I wanted to build one like this too.

MiniTrac (80mm x 100mm x 400mm) - by Intukun

The other design influence was closer to the Maker space. On Thingiverse, I found a great design of a robot tank by Tim Clark, MR6 - Mini Prototyping Tank Robot. Tim had obviously put a lot of thought into this design. This robot is at least his third design variant on crawling robots. Being his latest model, it probably has the most learnings. 

I really liked the skateboard bearings he is using, as well as the track design, and the various layers of support frame. Although, I am still not sure what is the advantage of raised cog/sprocket to form a triangle.  I did not use his design, except for influence - I needed to have the design in OpenSCAD, and he did not provide source files openly.

MR6 - by Tim Clark

I set out to design my own tracked crawling robot using ideas from both of these designs. In addition, I wanted to re-use 12V motors that I have harvested from old printers.

Track, Sprocket, and Motors -- Ready for Design!

Design Concepts


I want the motor to be inside of the treads, so that there is no axel crossing between a motor and the gears, thus raising the ground height of the robot frame.  Only the motor power wires and the mounting frame will need to go on to the track module.  Thus the height dimension of the unit will be dependent on the motor size and clearance of the treads and sprockets.

(Red) Motor between two sprockets, creating a contained track modual.

the width of the treads has to account for the width of the motor. This affects the width of the sprocket/cog.  The sprocket will contain a 22x7mm skateboard bearing.  So, ultimately the sprocket is dependent on the bearing size, and the tread is dependent on the sprocket.

Frame to hold the motor and sprockets

The length of the track would be dependent on the sprocket size, motor size, and amount of gear reduction needed between the motor and the drive sprocket.  This value had to be determined in a few design iterations. Also at play the size of the gears and the size of the sprocket are closely coupled. In my build process I needed to add size to the sprocket to account for the larger gears I needed.

Frame and Gears to drive the treads

The sprocket size was increased, to provide more clearance to the motor and gears. Since the sprocket gear tooth size is directly linked to the tread size, increasing the sprocket, but keeping the tooth size, meant that I needed an additional tooth on the sprocket.  Thus in a design iteration, changed the sprocket from 12 teeth to 13 teeth.  This very subtil change has impact on the rotational angle location on the sprocket disc. 

Size of the sprocket determine number of teeth in Sprocket and Tread size

Tread design

I examined Tim Clark's treads very closely. I also examined the changes he made from earlier designs to later ones. The result I saw was from early to later designed the length (size of step) of each tread was getting smaller and smaller.  This result in a more fluid chain of treads.

Wild Weasel - Tread Segment

To keep the build process simple, I am using small nails that slide through the Tread Segments to lock them together.

Gear Design

The gears used to transfer the torque from the 12v printer motors to the sprockets had to be carefully designed and fitted.  The motor has a high speed and needed to be stepped down in a compact space.
I experimented with gears reused from old printers.  the common design is a large top gear connected to a smaller gear on the same axis.  This provides a method to reduce the rotation speed for each gear step.
The motors had diagonal toothed gears already on them.  I used a open source gear library in OpenSCAD to design the gears.  Using more fine settings on the 3D Printer produced incredible results.

OpenSCAD library by Dr Jörg Janssen, Getriebe.scad.  I highly recommend this library, although it is in German. (don't let that scare you! ;)

One gear of 4 used in the design.

Final Design

Interestingly, building laterally symmetrical (no upside, downside) means you do not need to have a left or right side. the unit can be flipped or rotated to either side of the robot. By making two copies, I can rotate one tread around to have the symmetrical pair, without having to have a second design.

Track Modual

Here is assembly construction of the first robot.

Wild Weasel tracked Robot Chassis - OpenSCAD

Here is the first print made of the robot, complete with parts.  Completely 3D printed.

Printed Design - Wild Weasel Tracks and Robot

Robot Arcade - LetsRobot.tv

I am creating a "Robot Arcade" on LetsRobot.tv as a holiday project!  You can visit the site LIVE here:

Robot Arcade 

Robot Arcade - LetsRobot.tv

It is a work in progress, but works well to get all of the robot fantasy out of your head.  I am building this "robot" with mostly parts from recycled printers and some 3D printed parts.  It is using an L298N as the motor controller.  All driven by a Raspberry Pi that is streaming video and controls between it and the LetsRobot.tv servers. I will be using MQTT to pipe commands from the server to various computers controlling the scene.

In the first boot strap days, it was 'challenged' by the 'internet' robot operators.  my motors were not secured and were dancing around the scene.  Actually somewhat fun.  Today I put together this motor mount design and will be using it to build out the Arcade.

3D CAD designed to be a motor mount

I don't quite know what I will do with this yet, but I would like it to be some form of a remote robot - 'game of skill'.  it is fun to see some form of a battle or skill challenge performed by the remote operators.

I am open to suggestions for game ideas!  :)

TNERA now Robocasting on Letsrobot.tv

The Totally Not Evil Robot Army is now on LetsRobot.tv

you can now drive one of the robot, or many other enthusiast robots through the robot streaming system.

I have converted the original RC Cart Robot - Polybot, to be on LetsRobot.tv.

Polybot

check out the site (Polybot on LetsRobot.tv) and if the robot is streaming you can control it.

Are Remote Robot Games a 'Thing' yet?

In the past 2-3 years there is a convergence of technologies that are enabling the streaming and control of robots through the internet.  However, remote robotic control, for fun purposes like gaming is still in its infancy.  Why is this?  Why is remote reality gaming and robotic gamings still not a 'thing' (yet)?

The Convergence:
Maker based Robot Creation, Home internet broadband capability, low cost of components, converging with YouTube Streaming, Twitch Game Play, as well as the introduction of chatbots, AI, and ML are converging to make the concept of remote robot games a reality.

I would start to differentiate these as webcams on robots, exploring with robots, and games with robots.  The control of the robot could be observational, or first person.

The most basic - watching robot games on TV, like the picture below. This is very basic robo-sport.  It could be interesting, but in the current state is not very engaging.

I think the real interest in being able to engage with the robot from the internet.  Being able to steer it, perform some action, and potentially meet some (game) objective.

Robospatium
The best example of that in a non-commercial setting would have to be at Homofaciens.de. Homofaciens has build an environment (Robospatium) where you can remotely through the internet connect to a rover-robot and steer it around.  These robots have be working for many years, probably one of, or the first of its kind.  In addition to the robot rover, Homofaciens has a wealth of information for physical computing.  Norbert has a very successful YouTube channel with great videos on building your own robots from everyday items.

R11 Rover - Image from Homofaciens.de

Check it out >> the Original!  In English and German
Homofacian's Robospatium  (https://homofaciens.de/robospatium_en.htm)



Let's Robot.TV - https://letsrobot.tv/

letsrobot.tv is the work of Jillian Ogle. She has been featured on the cover of Make Magazine. She is setting out (like the rest of us) to make robots accessible to everyone, fun and enjoyable.  Letsrobot.tv is a platform where you can view and control remotely robots that are created and 'living' in robocaster's locations. 

There is a heathly community of robot enthusiast developing around Letsrobot.tv. Easy instructions are available how to create and add your own robot to the letsrobot.tv platform. In addition to open source code for the development of the robot, runmyrobot, on Github.

The platform supports a chat function allowing you to participate in the control of the robots with others. Having some of the local tokens, you can steer the robots and have them say things.

There are a few varieties of robots available on the platform.  This would include "The Claw" game, where you can remotely operate a claw arcade game and try to grab prizes from with in.

The letsrobot.tv platform is just gearing up now.  It has received a lot of publicity from MAke and the Makers fair.  It is notable that the platform is handling the video streaming quiet well.  This is one of the more important elements of a remote controlled robot.

Twitch Generation
It seems that the natural platform for the streaming of remotely controlled robots would be Twitch.tv.  Twitch is the streaming platform for electronic games where you can watch professionals and amateurs play video games.  Truly a sign of the times, Twitch itself is the convergence of streaming and gaming communities. To add to this, Twitch has added a creative channel that provides a means for artists and craftsman to stream their creations. So, it would be natural for a robot to stream as well - especially an internet controlled robot.  (Twitch is not alone, YouTube also realizes the value in streaming gaming)

TheOtherLoneStart - Twitch Chat controlled robot battles

One Twitch streamer has recognized this next step and created a Twitch chat controller robot, and associated gaming feature.  If you tune into TheOtherLoneStar twitch streaming channel you may find him building robots, or hosting a battle between his robots.  All for fun, you can certainly internet remote control the bots and have fun with them.  He also has videos of the builds, play action, and a HackaDay project.

Remote Games
Finally there is a new style of remote robotic games that have been created by "Remote Games".  Remote Games is a Ukrainian company that is also "living the dream".  They have created a game that allows for up to 10 (20?) special robot explore and compete an a intricately designed set based on a ghost town near Chernobyl. (yes, the site of the nuclear melt down)

Hyper real set from Remote Games - Image from Remote Games

The hyper-real set is amazing!  Here, with a subscription, you can explore the ghost town with a robot tank and compete in real time with others in different game formats.  The game company is planning to offer franchises of their gaming platform for others to operate their own arenas.  I would liken the model to that of 'laser tag' business plan, but with an Internet audience.

Interesting to note, one of the founder stated "we noticed how quickly remote-controlled game robots are gaining popularity". I think that there view point matches many in the maker/robot community.  we are only just now starting to see the new use cases of robots, robot games, and remotely controlled robots.  

I think it will soon become a 'thing'.