How do Smart bikes / Cycles work?

By Robin Malhotra — “On the journey to find the biggest Goliath and slay it down!”

There would be multiple Bikes/Scooters/Cycles in a city that are available on a various stations spread intelligently in the city. Where a customer would just scan the QR code of the bike and the lock would pop open and is available for the ride. After the ride is done, customer would put the lock back in its place and the system detects it and the customer app would allow him to end the ride. How does this happen? Well there are numerous steps involved so relax, get comfortable.

I would unthread the architecture that we followed to develop this system. This application took about 3 months to build and whole 1 year of fixes to reach its working capacity that it has now. This is being used in many cities outside India and mainly in major cities of India like Chandigarh, Delhi, Hyderabad, Chennai.

Each Bike would have an IOT device, a kind of a lock, something looking like this.

Now, these locks are capable of many services, main ones being.

1: Location Based Services: Sending Location Data at a set frequency.
2: Real-Time Data: Heartbeat data, Current battery, Voltage, Speed, Altitude.
3: Locking/ Unlocking Commands

These locks come with a documentation, that is made available by the manufacturer once the company buys the locks from them and these IOT devices would then be needed to get implemented using a server based architecture. Since these are IOT devices, it would be using the raw socket functionalities.

Since, our server side environment is node.js, our natural approach would be to use socket.io, which actually wouldn’t work, because socket.io requires the same protocols be used on both server and client side. So, we would be using node.js internal module “net”.

Now, this is used only when the device that you are implementing is socket based device. There could be some scenarios where the IOT companies delegate the firmware part to other companies and they implement all of it on there own server and can therefore sell the APIs, and you would need to implement those APIs. Well, they would also need to use this same strategy.

It is advised to follow the Micro-services Architecture here and design this server only for the IOT communications. So you need to set up a server and preferably a MongoDB or it can be a MySQL DB if you want on the same server. using MongoDB would actually be better since there are close to none relations between tables. Unless you want to have an optimized architecture of multiple types of devices with there types and all there commands stacked in the database itself, then using a relational DB makes more sense.

• 2 cores with 4 GB RAM and 2 GB Swap memory would be enough.
  * Start with 1 GB Database size, this is used to save the enrolled devices on the server, their locations and heartbeat data.

Handle Locations

1: Parse the locations from the incoming packet and expose them in an api (REST/GraphQL).

— ‘/update_location’. Use JOI for validations.

//Request Params
{"secret_key": <YOUR SECRET KEY>,"device_id": <123456>,"location": [ {    "lat": "30.3397809",    "lng": "76.3868797",    "tm_stmp": "1617952186837",  } ]}

• “location” will have an array of locations with time stamp.
• The device might send lot of locations, and when there are significant devices connected to the server, the server can get overwhelmingly bombarded with locations data. So it is essential to have an optimization.

2: For a particular device, start saving the locations data.

• For a latlng, form a 100m radius (Increase/Decrease based on device’s accuracy) and accept the next latlng only if it lies outside the 100m radius of the previous latlng.
• If the latlngs coming are too far apart, then use Google Directions API to plot the route on those latlngs.
• If the latlngs are coming outside the desired geofence, then send the alert to the device and a Firebase notification to the user.
• Sometimes device sends wrong or noisy locations, which would mean, the position you are getting is very far from the previous latlng. In this case, have a threshold geofence/radius on the previous location and any location far from that will be ignored. We can have a MAX_TRIES value that will count how many times the noisy location came. If it is more than the MAX_TRIES, we should consider that location because it could a valid latlng and the packet might have gotten delayed due to network or insufficient battery.

Handle Heartbeats

• Most essential data that we get in heartbeat is Battery Levels or Voltage. Sometimes, based on the Voltage we have to determine the Battery.
• It so happens that, a device will have a minimum and maximum voltage output based on how drained its battery is. So, we can use simple linear transformation algorithm to determine the battery.

//battery voltagefunction decodeBatteryOmniSmart(value){var base_volt = 320;var high_volt = 420;if (value < base_volt) {  value = base_volt;}if (value < high_volt) {  return Math.floor(((value - base_volt)/(high_volt - base_volt))*100);} else {  return 100;}}

• Based on the Signal Strength, we can alert the users if the device is operational or in bad network area.

Scalability

• Increase the instances of the server and save the [device_id <->socket_id] mapping in the elastic-search cache, so all the servers would know which devices are connected to the server.
• Make a separate server for IOT Device front and a separate one for Webhooks.
• Locations more than a THRESHOLD_DAYS :10 need not be stored, so we can have it removed to save space.
• Locations more than a THRESHOLD_DAYS :10 need not be stored, so we can have it removed to save space.

Meet the team!

Author
Robin Malhotra

Reviewer
Ajaypaul

Editor 
Mridula Saravanan

We at CaratLane are solving some of the most intriguing challenges to make our mark in the relatively uncharted omnichannel jewellery industry. If you are interested in tackling such obstacles, feel free to drop your updated resume/CV to careers@caratlane.com!