Controlling Romo with a Raspberry Pi
David Goeken
7/20/2020
Draft #1
Overview
The original Romo, the smartphone robot, by Romotive, was a
tank-like robot platform that was controlled via an iPhone�s or android's
headphone jack. It was a Kickstarter project. Romotive then developed Romo Version
2 � also a Kickstarter project. Romo V2 switched from using the headphone jack
to directly connecting to the iPhone 4�s 30-pin port and later the iPhone 5�s
lightning port.
I had a Romo and played with it using my iPhone 5. However, I
have since upgraded and my current iPhone no longer fits the Romo. In addition,
when Romotive went out of business the Romo App was removed from the App Store.
Fortunately, Romotive open-sourced the iPhone App along
with the Romo firmware. Others have used the open-source software to
continue Romo App development on the iPhone � the new App is available from the
Apple App Store for a fee.
I decided to
take a different approach. Using a low-cost USB logic analyzer, I have reverse
engineered the communication protocol between the iPhone and Romo. I am able to
control my Romo using a Raspberry Pi Zero to emulate the iPhone.
If one uses
the true meaning, you may say I hacked Romo. https://en.wikipedia.org/wiki/Hacker_culture
���������
First Approach
My first
approach was to use an Apple lightning male to female passthrough adapter
breakout board (APPLE-LM-LF-V2A) along with a low cost, USB logic analyzer (LHT00SU1
based) and the sigrok software.
�� ���������
Fortunately,
my iPhone 5 is functional and still has the original Romo App installed. After
hooking everything up, configuring sigrok, and plugging in my iPhone, I was
able to record the traffic between the iPhone and Romo.
After an
initial analysis along with some web searches, I was able to identify three (3)
phases of communication between the iPhone and Romo:
1. The iPhone negotiates with a chip in
the lightning connector for security along with determining which pins are to
be used for what purpose.
2. Romo tells the iPhone about itself resulting
in a request for the Romo App to be launched.
3. The Romo App on the iPhone sends
commands to Romo to control its behavior.
Since I realized
that I was no longer wanted to use the iPhone lightning interface with my Romo,
my next step involved opening up the Romo, knowing full well that this would
void my warranty 😊. There I saw a connector between the
Romo mother board and the lightning port. After moving the logic analyzer
probes into this connector, I ran another test with Romo and my iPhone. Results
were similar to the above but without the first phase of communication to
negotiate with the lightning security chip.
Very long
story short, after configuring a few pins, the communication is a relatively
simple serial protocol. I recorded and decoded the communication between the
iPhone and Romo. By having the Raspberry Pi emulate the iPhone, I am able to
control Romo using the Raspberry Pi.
Disassembling
Romo
First remove
the four (4) screws in Romo�s base. Romo also four (4) tabs holding the top
half to the bottom half. I put marks on the bottom of the Romo to help me
re-assemble the unit.
I was able
to slide a long finger nail file or letter opener between the wheels and base
and carefully pry the tabs open. With the wheels in the way, one can barely see
the tabs. So here is a picture of the tabs with one set of wheels removed.
The two (2)
blue semi-transparent end pieces add another level of difficulty to opening Romo.
The only advise I have is that one has to be careful and patient in removing
these two end pieces. The two end pieces appear to be identical, so the marking
may not be needed on those � although it is important to be able to identify
the top from the bottom. The two sets of wheels also appear to be identical and
with their built-in tabs, it is not possible to install them upside down. Even
so, the marking did provide assistance making sure everything was lined up for
re-assembly.
Here is an image
showing the main connector between the iPhone and Romo�s motherboard and an
image of the top section of the base showing the connector.
� ��������� ���������
Since I was
no longer going to attach an iPhone to the top of Romo, I removed the adaptor
by unscrewing the four screws from the top and removing the iPhone adaptor. In
addition, I removed the motor connected to the adaptor.
Analysis
using sigrok
My LHT00SU1
based USB logic analyzer is capable of measuring voltage levels and sigrok can
interface with it to act as an oscilloscope. This was used to identify the
function of the different pins on the connector and the voltage levels.
Initially I was not sure how I was going to interface with the Romo, but once I
discovered that it was a serial protocol using 3.3 voltage levels, I decided
that a Raspberry Pi was the tool I was going to use since the Raspberry Pi
operates using 3.3 voltage levels on its GPIO pins. I was contemplating using
an Arduino until I discovered the 3.3 voltage level protocol. In addition, the
Raspberry Pi was going to allow me to more easily add more features. In
development, the Pi having a WiFi connection and
being able to program it on the fly without having to remove the controller
were major advantages.
As stated,
after some quality time with sigrok, I discovered that Romo uses a serial
protocol. Two additional pins are used to get Romo�s attention. I do not plan
on fully documenting the protocol (at least not in this document), but will
give a high-level synopsis. One pin has to be tied to ground and another pin is
initially set to ground and then brought high � I have called this the control
pin. (I think this pin must be tied to some sort of reset pin on Romo�s CPU to
wake it from its power saving mode. Romo does not have an on / off switch and
its battery seems to last a long time when not used.) At this point Romo sets
it transmit pin high for a period of time before communication starts. Romo
first sends the iPhone information about itself, then the iPhone is triggered to
start the Romo App if it is not running, then the iPhone provides Romo some
information about the iPhone and the App, and finally the Romo app start to
command Romo. If there are no changes to the commands, multiple times a second,
the iPhone requests and Romo responds with status information.
I used
sigrok to record a few sessions with different app settings to be able to identify
the commands needed to set the three (3) motors� direction and speed, along
with controlling the LEDs.
But to give
you an idea, here a screen shot of a session:
And now
zoomed in to see a couple of packets:
Each packet
starts with hex FF 55, followed by 1 byte specifying the size of the payload.
The final byte is a checksum. The payload consists of the command or response
type, a transaction ID to keep things synchronized and to know what response
corresponds to what command, and additional information as needed.
Header Pin
Out
Here is a
close up of the connector.
I will start
numbering the pins from this picture�s left. I also traced the connector pins
back to Romo�s CPU; however, TXD and RXD appear to be reversed. The pin out
that I found to work for me:
Raspberry Pi
Pin��� Color��������� ��������� Romo��������������������������� ��������� Pin��� Comment
�1����� white������������������ ground������ ������������������ ��������� 6������ ground
�2����� gray����������� ��������� XCK0/T0/PCINT8��������� ��������� 6������ ground (tie to
ground somehow)
�3����� purple����������������� UART0_RXD����������������� ��������� 10���� GPIO 15 (RXD)
�4����� blue����������� ��������� UART0_TXD����������������� ��������� 8������ GPIO 14 (TXD)
�5����� green������������������ PA0
(ADC0/PCINT0)���� ��������� 12���� GPIO 18 control
�6����� yellow����������������� PA5
(ADC5/PCINT5)���� ��������� NC
�7����� orange���������������� PA6
(ADC6/PCINT6)���� ��������� NC
�8����� red������������� ��������� 5v
when charging������� ��������� NC
I found two
options to implement this wiring. First option is to use the existing connector
and solder on jumper wires to connect to the Pi. The existing connector wire is
very small � do not try using a knife to strip. I found that the �heat with the
soldering iron to melt and pull off� method to strip worked well. The second option
is to find a connector that fits � look for a JST PH 2.0 mm 8-Pin Female
Connector 16.5mm x 4.0mm x 6.5mm height, pitch:
2.0MM. Note: its wire
colors may be different.
Software
Again, I am
not going into a lot of details in this document; but at a high level, I used
the sigrok program to identify the baud rate used along with decoding the
contents of the communication packets. In addition, since Romotive open-sourced
the iPhone App along with the Romo firmware, that software was very helpful
with some of the details of the protocol � even though my Romo�s firmware is a
slightly different / older version.
To fully
document the protocol would take a document longer than this document and would
contain a lot of sigrok plots. The software that I developed contains the
necessary packets and correctly implements the protocol (AFAIK). The sigrok
analysis and software development took some time and was very iterative; but when
I first got it working and yelled, �It�s alive!�, my wife did come to see what
I was working on.
Modifying
Romo
In addition
to 1) creating the new connector between Romo and the Raspberry Pi, 2) removing
the iPhone adaptor from the top section of Romo, and 3) removing the unused
motor, I made the following modifications to my Romo:
4. I drilled out the four (4) holes on
the top section � keeping the small piece of plastic that attached to the top
and drilling through the top section. I found some 4 in x 6 in pieces of
plexiglass sold for picture frames and used it as a platform on top of Romo.
6. I extended the connector from the
unused / removed motor out to the top in case I found a use for it.
7. Added bolts on the plexiglass
platform for the Raspberry Pi.
8. Added a small breadboard area on the
plexiglass to add additional devices.
Here are a couple
of pictures of my modified Romo and platform without the Raspberry Pi or power regulator:
���������
Powering
the Pi
As stated,
to power my Raspberry Pi, I tapped into the existing Romo�s battery. My Romo
contains a Ni-MH 4.8v 2000mah battery. After fully charging, my battery
registered 5.5 volts. While running, Romo software provides data on the status
of the battery. During use, I measured and recorded the following:
Voltage��������������� Status��������
5.50 ���������� ��������� 828
5.39 ���������� ��������� 809
5.25����������� ��������� 790
5.20 ���������� ��������� 783
5.12 ���������� ��������� 772
5.10� ��������� ��������� 765
5.05����������� ��������� 760
5.02 ���������� ��������� 756
5.00����������� ��������� 748
4.95����������� ��������� 745
4.90 ���������� ��������� 727
4.86� ��������� ��������� 730
4.80 ���������� ��������� 718
4.78����������� ��������� 708
4.70����������� ��������� 700
4.64 ���������� ��������� 690
4.60����������� ��������� 680
4.50����������� ��������� 675
4.43 ���������� ��������� 666
4.33� ��������� ��������� 652
4.00 ���������� ��������� 600
3.90����������� ��������� 580
2.76����������� ��������� 500
This makes a fairly linear chart.
The
Raspberry Pi is generally specified as operating from 4.75 to 5.25 volts. This
does depend on which Raspberry Pi model is used. Thus, a voltage regulator is required � one that can both step up and
step down. I am using the S9V11F5 Buck Boost Converter. This device efficiently
produces 5 volts from input voltages between 2 and 16 volts with typical
maximum continuous output current of 1.5 A. This is sufficient to power my
Raspberry Pi Zero. My software monitors the battery�s status and shutdowns when
the status is 675 � when the battery voltage drops below 4.5 volts.
There has
been some debate on how to connect this power to the Raspberry Pi. One can
either strip a USB cable and power the Pi the normal way or connect 5 volts to
the GPIO pin #2. There is no regulation or fuse protection on the GPIO to
protect from over-voltage or current spikes. If an incorrect voltage is
applied, or a current spike occurs on the line, you can permanently damage your
Raspberry Pi. However, it is reported that the Pi Zero does not have a polyfuse, so there appears to be no downside to powering
from the GPIO.
Video
I quickly
created a video to demonstrate the Raspberry Pi controlling Romo. I tried to
show the test program running and how Romo reacts to keyboard input in the same
shot. I used remote desktop to display the Pi�s console. First, I exercise the
LEDs and then the tank track motors. It is run on my development Romo � with
wires sticking out all over and the Pi is not attached to the Romo platform and
is powered externally. Sorry for the very poor quality and for hosting it on a
bandwidth challenged server. I�ll try to create a better video.
http://dhgoeken.com/Romo/romo_pi.mp4
Future
Plans
I have a
version of my software that demonstrates and tests the Romo. It can control the
LEDs (brightness and can blink them) and it can control the motors (speed and
direction). It would be useful to convert this into a library once fully tested
and additional features added.
Add
ultrasonic sensors to create an autonomous vehicle.
Add a camera. Add other sensors � temperature / humidity, line following. Interface
with MQTT. For testing I have acquired multiple Romo vehicles, so an autonomous
fleet of vehicles that can communicate among themselves.
Add a
display to the Raspberry Pi. Use it to monitor activity and to emulate the
original Romo App�s facial expressions.
Add a
speaker to the Raspberry Pi. Use it to emulate the original Romo App�s
behavior.
Add a
microphone to the Raspberry Pi along with the above features to develop a
telepresence system.
The tank
treads run at different speeds for the same setting. I want to calibrate the
two so that it can more easily run in a straight line.
Utilize the
third motor or replace it with something else � I believe the output uses pulse-width
modulation (PWM). In the original Romo this motor�s travel is restricted. Once
removed the motor can constantly rotate like the others on the tank treads,
although much slower. One of the status responses reflects each motor�s current.
I believe that for this third motor the current was used to identify when the
motor has stopped. Add monitoring each motor�s current to identify if Romo gets
stuck against an object.
Additional analysis
of Romotive open-sourced iPhone App and Romo firmware to identify additional
features that can be incorporated into the Raspberry Pi�s code.
Romo has a
JTAG port. Look into flashing the Romo with custom firmware. The current
firmware has some unneeded functions. It may be possible to remove that code
and add new code that could make the need for the Raspberry unnecessary.
It may be
possible to utilize the unused pins on the connector; but that may require
reprogramming Romo�s firmware.
This may
become a living document in that I may add to it as new things are developed �
check back later for updates. If time permits, I may better document the
protocol that I am using between Romo and the Raspberry Pi.
I am open to
input from others to identify desired enhancements.
Additional
Notes
For
completeness, I purchased an additional Romo that was for the iPhone 4. Some
Romo motherboards are attached to the top half whereas others have their motherboard
attached to the bottom half. So, depending on the Romo model, the technique to
completely disassemble your Romo is a little different. I was initially worried
that I would have to purchase an iPhone 4 and breakout board, and then somehow
put the Romo app on the iPhone 4 to identify the pins used for its serial
interface. However, the motherboard�s connector is identical to the iPhone 5�s
� the iPhone 5 has an additional resistor on the connector going to the top
that appears to be used by Romo�s firmware to differentiate whether it is
connected to an iPhone 4 or 5. I did not review the firmware code to determine how
that information is used. I plugged my Romo�s iPhone 5 top onto the Romo iPhone
4 base and everything worked! I did a few recordings using sigrok to identify
any differences. My software is able to control both the iPhone 4 and 5 based Romo.
My test software
is written in C.
I have tested
the software on three Romo units. Aside from things like the serial number, all
packets from the different Romo units appear virtually identical. One packet
from the iPhone to Romo appears to be unique; however, it appears the contents
of the response does not matter � i.e. I have been
able to use the same response to multiple Romo units. I am trying to identify
the differences.
This makes
me wonder if other iPhone peripherals use a serial protocol.
Romo�s CPU
is an ATmega324P, 8-bit AVR RISC-based microcontroller.
Romo
controls the motors using BD621xxx series DC brush motor drivers.
Any
Raspberry Pi should be adequate to control Romo. Not sure about a Raspberry Pi
Pico � but that would be an interesting project.
I use remote
desktop on my Raspberry Pis.
I mount a
Windows shared folder to back up my Pis.
Shameless Plug
I do this
and the other things* not because they are easy, but because they are fun.
(Apologies to JFK)
Please let
me know if anyone:
1. is interested in helping me continue
this project,
2. likes this project and wants to support
my hacking habit (I can provide a PayPal account for pizza money),
3. wants to buy a Romo modified for use
with a Raspberry Pi (I could put some on eBay),
4. wants me to modify their Romo.
One can find
inexpensive Romos on eBay � at least you could. This
project could influence their price. If so, I can provide a PayPal account to
receive thanks from sellers 😊.
I created a gmail account until I find a better home for this project (github?). The current web site may be bandwidth challenged.
I am not sure how often I will check that email account � I do have a full-time
job.� [email protected]
Resources
https://github.com/Navideck/Romo-Firmware
https://github.com/Navideck/Romo
https://github.com/Navideck/Romo-X
https://github.com/Navideck/Scratch2Romo
https://github.com/Ushnash/Romo
https://github.com/champierre/Romo
https://github.com/champierre/Scratch2Romo
https://github.com/champierre/Romo
https://labs.laan.com/blog/make-an-arkit-robot.html
https://sigrok.org/
https://nyansatan.github.io/lightning/
https://www.pololu.com/product/2836
https://www.microchip.com/wwwproducts/en/ATmega324P