TLDR; I skinned a dog toy, slapped an Arduino on its posterior, and then commanded it to move over radio.
Overview
This was an unhinged teaser I wrote in a blog post years ago. I think it speaks to what happened to poor Bubbles. I will (of course) go into greater detail later in the post.
OK so now onto the secret project. Well it is not really a secret and in fact my g+ picture is of him. Its my robotic dog bubbles, so far just a simple deskinning of a toy dog and screwing an Arduino to his posterior have turned him into the most amazing puppy of them all. However he is not complete. Last weekend I did get his neck removed from the gear box and now have it driven by a servo. Also I have given him the ability to backup since the manufacture decided that toy dogs can’t go backwards. This led to an amazing adventure in time travel… er gearbox rebuilding that kept me pleasantly entertained for hours of useless time. Here are some pictures of this fun.
Remember when G+ profiles were a thing? It has been a while since I visited this project.
Origin Story, Timeline, and Musings
Bubbles wasn’t always in such a sorry state. He (originally a she) was a gift my little sister received (for Christmas or birthday, I forget which). The toy line was Hasbro – FurReal Friends – GoGo, My Walking Pup. My sister enjoyed this toy for a time. Then as she got older, it was neglected in the closet, gathering dust and battery corrosion. By the time I received it, Bubbles was ready to be sent to the garbage bin.
I couldn’t do much in regards to the fur matted with grime and leaked alkaline deposits so I carefully removed it (pleasantly referred to as skinning). The battery box was ruined as well so cut that out.
I then replaced the battery box with two 2x C battery holders from Radio Shack wired in series. I shoved these back into the old battery holder space. I had to move the power switch which was originally integrated into the battery box to outside and underneath Bubbles (hence male).
Some sketchy mechanical implementation of a battery box cover / holder later and he was up and running.
Not the prettiest battery box solution but it held together well enough to work on the more interesting control problems.
Next, I needed to figure out the controls mapping. Bubbles had a wired remote leash with buttons for forward, backward, left, and right. I chopped off the remote and wired it up to a switch breakout. Once I documented the common wire and the control wires, I purchased a relay shield (also from Radio Shack), and wired everything up to an Arduino Uno.
I mounted the Arduino stack to the posterior of Bubbles. The robot body had a cutout perfectly shaped for it already, which was really handy.
It was then time to write the first control code. I used a modified version of Roverbot’s control state-machine as the steering operations were similar. In fact, for a while, I had also included an ultrasonic sensor that I hot glued onto the front chest of Bubbles.
After this initial control work, I realized a couple things to be improved. First, I wanted to add an RGB LED to Bubble’s translucent head in order to signal emotion. Second, I needed independent control of Bubble’s neck (again to signal emotion). Third, I needed better control over the drivetrain. Lastly, I wanted to remote control Bubbles from my PC.
Plenty of space in the head for RGB LEDs.
The head / neck changes were pretty straightforward. I had to do a teardown of Bubbles to place the LEDs and route the power, ground, and signal wires. Likewise, with the servo motor for neck control. The only challenge there was disconnecting the old gearbox. I couldn’t reuse that gearbox as it was multi-function based on a directional clutch.
Gearboxes inside of toys are often fairly elaborate. Probably cheaper than having another motor on the BOM but …uhg… makes the toy more difficult to hack.
The drivetrain motor / gearbox was also a problem as it was multi-function with forward / backward plus tail wag. Bubbles would randomly stop moving, go forward, or go backward even when commanded to walk by the remote. I wanted to keep the gearbox as original as possible, but at the same time have predictable control for the autonomy state-machine. My solution, was to tap off the control signals to the motor and the motor itself into a header. Worst-case, I could jumper them to get original behavior. Best-case, I have access to control state and can direct drive the motors.
Header with motor breakout and control breakout. Janky but sufficient for testing.
This attempt to control the motors did not work as well as I would have hoped. This is not due to the idea being bad but the execution to be a bit out of my skillset at the time. However, in building this system, I built a lot of the foundational skills needed for later projects, education, and career.
Debugging motor control board built on a protoshield. Needs a Rev2.
Lastly, I wanted to control Bubbles over radio. To do this I purchased two XBee radios configured as a UART pair. One connects over UART to the Arduino. The other, through a breakout board connects to the PC over USB as a virtual UART. I also 3D printed a little red enclosure for the PC side radio.
Excuse the poor quality image. Shown is Bubble’s posterior with the XBee radio dangling off the relay board.
Next, I had a new version of firmware to write. I refactored the autonomy state-machine, added basic control of the LEDs, neck servo, and motor controller, in addition to the relay control. Then, I built out a JSON control structure to communicate between the PC and the Arduino over the XBee UART link. Bubbles’ firmware would have both a teleoperated mode and a lower-level autonomous mode.
This development effort went so-so. I end up completing the version of firmware and developed a python app that served a webpage for control. You check out the Github repo here.
View of Bubbles from the front. Isn’t he adorable?
Hardware Summary
The current state of Bubbles is in dire need of repair. But before I do that (as another post) I want to document what we currently have, what needs a rethink, and what needs to be purchased.
Outlining the future goal of Bubbles:
- Repair to functional teleoperated control state
- Rethink power subsystem
- Rethink sensor input
- Previous was ultrasonic
- New, perhaps camera?
- Rethink drive motor sense/control
Current state of Bubbles; in need of repair and improvement.
Current hardware:
- Bubbles RC Chassis
- Drive Motor
- Tap off for monitoring / control
- Steering Motor
- Modified neck w/ RC servo
- Modified head with RGB LEDs
- 4x C battery box for chassis power
- Wiring for ultrasonic sensor
- Possibly repurpose-able
- Fix neck servo motor
- Causes brownout
- Drive Motor
- 9V battery box for Arduino
- Arduino stack
- Arduino Uno clone
- Custom (non-functional) breakout board for drive motor control
- Relay board for chassis “RC” control
- XBee serial radio
- XBee serial radio to USB for PC
Needed hardware:
- Stand / block for Bubbles while testing firmware
- Perhaps 3D print this?
- FPV camera + Radio Transmitter & Receiver
- Media adapter radio receiver to video input for PC
- Control PC
- Perhaps a Nvidia Jetson Nano?
While writing this post, I stubbled upon an old schematic I drew for Bubbles. Keeping it here for documentation purposes.
Schematic for Bubbles with first attempt at the motor controller.
Firmware
The firmware is in a bit better shape that the hardware. I followed a similar firmware architecture to Roverbot with base drivers for servo, relay board, ultrasonic sensor, RGB LEDs, and motor controller all being wrapped into a higher level BubblesHardware object. The hardware object is a shared resource between teleoperated control and the autonomy state-machine (again using roughly the same logic as Roverbot).
I am not going to deep dive into it here since I will be reworking it anyway in another post.
Check out the current firmware on Github here.
Software
Bubbles consists of three intelligence layers as depicted in the image below. The architecture loosely follows the subsumption architecture popularized by Rodney Brookes with each intelligence layer controlling the lower layers in a horse and rider fashion.
Layer architecture diagram with control signals.
Layer one consists of the physical construction, mechanical systems, and built-in electronics of Bubbles from when he was a toy. Some changes were made to this layer to better control the behavior of Bubbles but the overall goal is to let the low level behavior guide the body. This layer will accept commands that follow the signals used to control the “walking the dog” remote control. One specific change to this layer from the original factory version is the exposure of the drive motor control signals to better control movement of Bubbles.
Layer two is constructed with an Arduino microcontroller, custom drive motor controller shield, Seeedstudio ultrasonic sensor, Seeedstudio relay shield, generic RGB LED ring, generic micro servo and an XBee S1 radio as shown in the schematic. The connections to the first layer allow for control of Bubbles through the Arduino to run the autonomous algorithm developed.
Layer three is a PC interface using the XBee radio for wireless communication. The control application exposes the option to turn off Bubbles’ second layer, thereby allowing the hardware to take control of the body or to enable layer two in either manual or autonomous mode. Manual mode allows for wirelessly moving Bubbles through finite commands, such as forward, backward, left, and right. Additional controls include RGB LED settings and head position. Software for this layer is a Flask application written in python for the server with HTML / Javascript for the UI.
Bubbles has achieved minimum proficiency as a robotic pet with autonomous and manual control modes. Through the use of a horse and rider design methodology the different intelligence layers can express various behaviors to make Bubbles an active agent in the world.
The main problem, currently, is the hardware (layer one) ignoring movement commands after a period of time. This problem appears to be a protective feature of Bubbles’ as toy so that a child may forget about Bubbles and waste battery life. Currently, my approach is the refresh the control signals to Bubbles periodically by disabling any active relays for a short duration of time. A future goal is to tune this process, along with power cycling Bubbles hardware if he becomes completely unresponsive.
Closing Thoughts
Bubbles was one of those projects that never quite went right. I think part of it was that I was still early in my engineering skillset and was stretching a bit. But the project itself also lacked from a clear vision of what Bubbles should do. I still don’t know if I have a clear picture. Maybe, its enough that the Bubbles project is re-engineered to be a decent platform for a PC controller / AI.
Watch for a new post of Bubbles in the future. My intent is to wrap up the hardware and firmware portions. Software will probably be a separate post way down the line.
