How Our High-Tech Mobility Mixes Robotics and Bikes
I am proud that at Greyp, we are more than a maker of award-winning electric bikes. We are a high-tech mobility company powering forward to build out a connected mobility platform. That is why the company has this month launched a digitalized equity offering for retail investors to own a piece of Greyp and help us realize the vision of our CEO Mate Rimac of zero accidents, zero ownership and zero emissions.
It has been humbling for me to see the support we have received from our community of bike owners (in addition to our existing major backers such as Porsche, Camel Group and T-Mobile). I am confident we have laid a strong foundation for this connected mobility future — because innovation is in our DNA. As Greyp’s Embedded Team Lead, I feel it every day around the company. More than half of our 70-strong team is in R&D. And I like to think the results speak for themselves through our bikes, on which you can watch videos, observe your data and enjoy an awesome ride too.
So, I wanted to share a little about how we marry technology with engineering to produce our Greyp e-bikes. I wanted to take you on a tech dive to share some of the ways we combine smart tech with a great ride so that our bikes thrive on robotics.
Running ROS on a bike
INTRO
When I mention to my former fellow roboticists how we are using the Robot Operating System (ROS) [1] as a base development framework for the Greyp bike [2], they usually raise their eyebrows in an expression of faint disbelief. And why shouldn’t they? They are used to seeing ROS on machines where computer resources are less of an issue. A bulky control box might be placed somewhere next to the robot without interfering with the robot’s workspace. In such a control box you can more easily fit the hardware needed to run the desired software application.
A bike surely doesn’t fit this description. The hardware needs to be compact, and the “control box” lightweight and small. Furthermore, doubts may increase when you realize that the bike integrates camera streaming and recording, machine-to-machine communication (M2M), a bunch of various sensors such as barometer, GPS, accelerometer and gyroscope and communication channels: Bluetooth, USB and WiFi, CAN communication with the battery, motor and joystick controller.
Despite all of this, having an embedded system like a bike controller running ROS is a reality.
The goal of this article is to provide a brief overview of how the ROS is utilized in our biking context.
ROS ON GREYP BIKE
At its core, ROS is a software robot operating system middle-ware for interprocess communication leveraging the publish-subscribe and a Remote Procedure Call (RPC) paradigms. In principle, a ROS application is developed as a distributed application. Here a number of processes, called nodes, are each in charge of their own functionality and exchange information between each other. ROS nodes may live on the same machine, or on different machines. It doesn’t matter where the nodes are, as long as they are on the same network.
ROS TOPICS
In ROS, the publish-subscribe paradigm is achieved through ROS topics [3]. A ROS topic is a construct used when you need to send a unidirectional data stream. A single ROS node publishes data on a topic, while the other node subscribes to the topic and consumes its data. When a node wants to publish something, it registers with the ROS master. The other node, the consumer node which subscribes to a topic, also registers with the ROS master to know where to get the data.
On Greyp bikes, we use topics to stream metric data between nodes. This includes speed, battery State of Charge (SoC) and much more. To provide a clearer example, I will illustrate this on our video streaming feature (see Image 1). The bike’s video streaming from the bike’s cameras to the mobile device is implemented with ROS topics. Here a Camera Node holds all the functionality related to the camera hardware integration. A Camera Node communicates with the camera and obtains encoded camera frames. These frames are then packed into ROS topics and published. If a mobile phone is connected to the bike over USB, the USB Node subscribes to the topic and streams the encoded camera frames over USB to the mobile device. The USB Node holds all the functionality for USB communication.
ROS SERVICES
ROS services are a mechanism to implement interprocess RPC between ROS nodes. Services are used for Request/Reply types of communication. The client, which issues the Service call, blocks and waits until the Response arrives from the Service server. Only a single server may exist in the system, while a number of clients may issue the calls to the service server.
As an example of how the ROS services are used on the Greyp bike, I will illustrate a feature we call “Acquire photo” (See Image 2). With “Acquire photo” the user can fetch a photo remotely from the bike and see it on a mobile phone. The command to “acquire photo” is issued to the bike over the Greyp Cloud services. Here an Mqtt protocol is used to exchange information between the bike and the cloud. The bike receives a message in a ROS node called Mqtt Node. This message is packed into a ROS service Request and a call is issued to the main state machine of the bike. The state machine lives in another ROS node called Master Node.
The state machine is in charge of processing all incoming user requests as well as the bike’s system state. The state machine interprets the message as an Acquire photo message and makes another ROS service call to the Camera Node. The Camera node gets the camera snapshot and packs the image in a service response. The state machine then responds to the Mqtt Node that a picture is taken and the location where it has been stored in the cloud.
APPLICATION ARCHITECTURE
While discussing the ROS services and topics I gave a glimpse of how the node architecture is defined on the bike. The goal is always to pack the functionalities which share the same denominator into a single corresponding node. Referring to the previously described use-case, the Camera Node is in charge of all camera-related tasks. It exposes a number of services and topics for the other nodes to interact with it (e.g. take a snapshot, start/stop streaming, etc.). Master Node understands the system and centralizes the state-dependent decision logic. Mqtt Node knows how to communicate with the cloud but doesn’t know what the payload actually means. The payload is interpreted by the Master Node.
We currently have around 20 nodes running on the bike which are exchanging 30 topics and expose 40 different services.
CONCLUSION
The bike is out there. As a user, you can ride it, watch videos, observe your riding data, and enjoy the awesome rides (don’t take me as biased on this one, this is really true :)). As a developer, I can easily add new functionalities inside the system. Plug-in new nodes or remove and replace the current ones. ROS offers excellent debugging services since you can monitor all topic traffic.
PROS
What do we like about ROS? I would say this is the clear decoupling of functionalities inside their own processes and a seamless way to integrate these through ROS services and topics. One can run a ROS node while the bike is running, turn the node off or re-run the node in case of a problem. With ROS, it is quite straightforward to achieve such a distributed and modular architecture.
CONS
What don’t we like about ROS? Somehow the boot-up time is quite slow. It takes a while for all the nodes to get up and running. ROS doesn’t guarantee the boot-up order of processes. We had to develop our own mechanisms to ensure that processes wait for each other when they first start. This mechanism is suboptimal as we are slowing down the boot-up time. I was also quite annoyed that I couldn’t turn off the default ROS logging mechanism. Boot-up of the logger also eats-up a part of the boot-up time.
FUTURE WORK
At the moment, the bike integrates a variety of sensors. But we do not plan to stop there, there is still some juice we are planning to squeeze from the bike. We are working now on a Kalman Filter to fuse sensor information and achieve a more accurate estimation of the bike slope for uphill and downhill measurements. And to make the bike a really smart-bike, we will add machine learning algorithms to help distinguish when the bike rider crashed, or when it is just running a crazy down-hill ride. With ROS, adding such features will be an easy ride, and integration-wise we do not expect too many difficult trails ;).
REFERENCES
[1] http://wiki.ros.org/
[2] https://www.greyp.com/
[3] http://wiki.ros.org/Topics
[4] http://wiki.ros.org/Services
Stay up to date on Greyp and our digitalized equity offering where whitelisting started on Monday, September 23:
- Website: invest.greyp.com
- Twitter: https://twitter.com/GreypBikes
- Instagram: https://www.instagram.com/greyp_bikes/
- Linkedin: https://www.linkedin.com/company/greyp-bikes/
- Facebook: https://www.facebook.com/GreypBikes
- Telegram: https://t.me/ETOGreyp
