Close
0%
0%

Kaukomieli - a telepresence bot

A telepresence robot on the cheap

Similar projects worth following
Using an old Android phone, an Arduino and a wheeled robot platform to construct a telepresence robot.

So one day I stumbled upon the website of Double Robotics, a company that makes telepresence robots. Sort of fancy combinations of an Ipad and a Segway. What would it take to make a DIY version that's suitably close to the same feature set?

A telepresence robot should have the following features:

  1. The telepresence bit, that is two-way video and audio.
  2. Remote control
  3. Mobility

1. Telepresence

We need something with a screen, a camera, speakers and a microphone. Since the robot will have a limited carrying capacity a mobile phone is the obvious choice. I had an old HTC One for this purpose.

But what about the software side? A teleconferencing app is the first thing that springs to mind. First I though about Google Hangouts since it's readily available for many people. But this robot would only be useful if the user can open the conferencing connection whenever she wants without somebody answering the call on the robot's phone. Hangouts doesn't make that possible.

So next up was Skype. Skype has the suspect feature of auto-answering. If enabled Skype will automatically accept all calls from known contacts. This is very convenient for the robot. A new user can be added just by adding her as a contact in the robot's Skype client.

There's just one hitch: auto-answering doesn't work if the phone's display is off. So I needed a way to wake the phone before making he call. Which brings us to the next feature.

2. Remote control

A mobile phone can very easily connect to a local WiFi or use the mobile network to make itself available for remote control. So we want to have the robot available as soon as it's connected to the Internet, without concerning ourselves with its network address. Using an MQTT broker to pass the commands to the robot suits this requirement perfectly.

An Android client can access MQTT topics by using the Paho MQTT library's service. I wrote a little app that starts a long-running Android service which uses Paho to listen to a control topic. With the suitable permissions we can force the phone to wake up. After that opening the video connection is really easy; first command the phone to wake up through MQTT, then make the Skype call which is automatically answered.

The detailed flow pretty much goes as follows:

  1. The user starts the mobile app.
  2. The user starts the messaging service from the app. The service connects to the MQTT broker and subscribes to the control topic.
  3. The service runs in the foreground so that it's not shut down by Android and acquires a partial wake lock so that the Paho MQTT service can also run even if the phone is not in use and the screen is turned off.
  4. When the remote user wants to connect to the robot by Skype she sends a wake-up command to the robot from the web UI. This forces the phone to turn the screen on and acquires a full wakelock so that the phone can't go back to sleep.
  5. Now the Skype call is made and the phone's client picks up the call automatically.

MQTT is also used to control the movement of the robot. The electro-mechanical side of things is handled by an Arduino Pro Micro. The Android phone needs to have some way of relaying the commands to it. Since I already had some HC-06 modules around Bluetooth was a natural choice. So when the Android client receives robot movement commands it just relays them though the Bluetooth serial port and the Arduino sketch does the rest.

So what about the remote control UI? I preferred not to have a full web application with a server back-end as that would make things more complicated. And sending the robot commands first to a back-end and from there to the robot would introduce more lag to the controls. Fortunately the MQTT library for Node.js [see links] can be used directly from a web application. This does however mean that the MQTT broker needs to support WebSockets.

I'm using Mosquitto and by default it doesn't support WebSockets. But that can be enabled separately. [see links] The web UI itself was made with Clojurescript and Reagent. Direct WebSocket communication...

Read more »

  • 1 × Arduino Pro Micro Servo and motor control
  • 1 × HC-06 Bluetooth connection between the phone and Arduino
  • 1 × L298N Dual H-bridge motor controller for the robot's wheel motors
  • 1 × 3A UBEC Power regulator
  • 1 × 1300mAh 11.1V LiPo battery Power source for all the components (except the phone)

View all 8 components

  • Out of time(rs)

    Harri Ohra-aho02/28/2016 at 21:15 0 comments

    The robot is always veering a bit to the left, probably due to the motors being a bit unbalanced and/or crooked wheels. The logical way to remedy this would be to lower the PWM value on the right side motors so they'll run a bit slower.

    But if I reduced the PWM value below 255 the motors stopped running altogether. The reason for this is found in the PWM pins used and the amount of available timers on the Pro Micro. The board has PWM capability on five pins; 3, 5, 6, 9 and 10. Timers are needed for PWM and timer number one is used by the servo library. Pin 9 currently used for controlling the forward rotation of the right side motors. Looking at the timer / pin definitions for the Pro Micro reveals this:

    TIMER0B,/* 3 */

    TIMER3A,/* 5 */

    TIMER4D,/* 6 */

    TIMER1A,/* 9 */

    TIMER1B,/* 10 */

    Left side motors run ok with full PWM control in both directions since they're controlled by pins 3 and 5 with no timer conflicts. Right side backward rotation on pin 6 is also ok since it has no timer problems either. But pin number 9 needs the same timer 1 as the servo library.

    This causes all PWM values below 255 to effectively mean zero in pin 9. Moving to the last PWM pin number 10 wouldn't help either as it's also dependent on timer 1.

    There's a couple of possible solutions.

    1. Switch from the servo library to the old PWM servo library. It should eliminate the need for the timer. The servo needs to be connected to pin 9 or 10 though.
    2. Rearrange the motor wiring so that pin 9 is used for reversing, as a little veer there isn't really that bad.
    3. But the best option should be to apply a bit of PWM on the reverse pin of the right side when moving forward. That should lower the power output suitably.

  • Rubber band to the rescue

    Harri Ohra-aho12/06/2015 at 17:09 0 comments

    As I didn't want to keep the servo powered when the tilt bracket isn't used I ran into a small problem. I would detach the servo after tilting the phone but sometimes the mechanical friction of the gears wasn't enough to hold the phone and the bracket in place and they would dip to the lowest position.

    This can be helped a bit by waiting for a while before detaching the servo after rotating it, so that the gears aren't in motion anymore when the servo loses control.

    But as the medium servo isn't really that powerful even this wasn't enough sometimes. The bracket would still dip. I thought about adding a counterweight on the other side as now all the weight was on the side of the phone. But I didn't really have anything with enough weight in a small package.

    So another low-tech solution to this was to pull a rubber band from the top of the tilt bracket down to the robot chassis. It nicely balances the weight of the phone and the servo no longer rotates uncontrollably to the low position.

  • A simple solution to the start-up brownout

    Harri Ohra-aho12/06/2015 at 17:00 0 comments

    Since there are a couple of capacitors on the circuit's power rail there's always a bit of residue charge when the battery is disconnected. I noticed that this can be used to alleviate the voltage dip. So the simplest solution to the problem without adding anything extra is: power up, power down, then immediately power up again. And the bluetooth starts without hiccups.

    Slightly ugly, but good enough for now.

  • UBEC, why u no power

    Harri Ohra-aho12/05/2015 at 20:05 0 comments

    The UBEC seems to be the culprit for the start-up voltage dip. If the battery is first connected to the UBEC and only after that it itself is connected to the rest of the circuit, everything works ok. So it seems the UBEC needs settle for a moment before it can properly supply the whole circuit. Unfortunately the servo doesn't care for such tardiness and resets immediately.

  • Servo and Bluetooth blues

    Harri Ohra-aho11/28/2015 at 22:41 0 comments

    For some reason when the Arduino is started and the servo resets to its default position the HC-06 fails to start up properly. If the servo is connected after the start-up everything works fine. I guess there's some kind of an interference or drop in power due to the servo and the HC-06 starting up at the same time, even when neither of them are powered from the Arduino. A capacitor between VCC and GND doesn't seem to help.

    Switching the servo power on separately with a switch or a transistor should fix the issue if nothing else works.

View all 5 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates