Close
0%
0%

Bástya 2.0 (work in progress)

Our latest robot for telepresence and VR experiments.

Public Chat
Similar projects worth following
We want to build a robot platform prototype, what can be used to experiment with telepresence augmented with virtual reality headsets, and controllers.The goal of the project is to make an universal base. It can be upgraded with custom parts to solve specific problems. This is the next version of the robot.This version is heavily work in progress, and in early stage! The new main planned features of this version:- Adjustable "eye" level (human like height)- Robotic arms, remote controlled with the VR controllersPrevious versions:https://hackaday.io/project/26073-bstya-v15First prototype:https://hackaday.io/project/11956-robot-for-telepresence-and-vr-experiments

For the most detailed description please check out the project logs.

It is streaming video on wifi, and listen multiple sockets for head tracking control, and movement control.

Currently we are using HTC Vive for the development, but it can be operated with similar PC connected HMDs.

Besides that, you can connect to the robot with HTML5 compatible browser and watch the video stream. Because of the HTML5 we can send the mobil device orientation back to the robot, so it can adjust the camera position in real time. You can control the robot movement with joystick connected to PC, or tablet.

If you don't know something what we did, why we did that way, feel free to ask, and I will try to answer it.

We are glad if you make suggestions, or tell your ideas to improve our robot.

View all 22 components

  • Progress in the past weeks

    BTom05/02/2021 at 00:09 0 comments

    We finished with the chassis for now, and made belt tensioning.

    The electronic installation is completed with voltage regulator, mikrotik router, programable touch screen, arduino mega with our custom shield. The cable connections to the motors looks fine at first, but at testing we found out most of the cabels are too fragile, so next week we will replace them.

    We are using the Mikrotik hap ac2 routers https://mikrotik.com/product/hap_ac2 One on the robot, and one at the remote control PC. These are bridged with nv2 protocol.

    Today we placed the head on top of the robot, and it looks like we will have to make some resonance dampening, but it will works.

    At programming side we finished with the first version of the arduino mega code, and the python programs for remote controlling (robot and PC side) . We made progress with the new head controlling algorithm we will post details .

  • New parts arrived, and the head mechanics nearly completed

    BTom04/17/2021 at 12:46 0 comments

    In the past weeks we wait for parts to arrive, and we rearranged the workshop because in the past year we rarely used it.

    Only the PWM shield not arrived yet. That's will be needed for the head mechanics.

    Camera for the stereoscopic view

    Meanwhile, the plans for the new head mechanics completed, and the first version is 3D printed. The previous version is working too but we want to upgrade it to be more stable, and less demanding for maintenance. The is based on the adafruit animatronic robot head, we modified it a bit, for our requirements. https://learn.adafruit.com/3d-printed-animatronic-robot-head/design

    base of the head mechanics
    head mechanics
    head mechanics parts

    The programming is progressed too, but nothing spectacular. Currently we can send data from the OAK-D to the unreal engine.

    The next step is to display the data in the unreal engine. The data package currently contains camera ID (so we know which camera is sending the data. Its defined in a config file which camera is placed what side of the robot.) and the recognized object, and it's coordinates with distance (x,y,z)

    We are currently discussing the remote control of the robot in the team. The are 2 competing solutions:

    The joystick connected to the unreal engineThe joystick connected to the EssortRobotController
    pro:
    - in the future we want to test other control solutions than the joystick
    for example walking in VR will be simpler if the remote control already
    implemented at the unreal engine side
    - we can simulate the movement in a virtual space without the robot
    it will be much easier to test the out the solution
    - we can use the unreal engine collision model to stop the robot

    cons:
    - the robot is only usable with unreal engine 
    (we can't remote control without it)
    - generally not a good idea to implement collision avoidance
    at high level
    - it will add some overhead time to control the robot.
    probably negligible
    - we have to use RawInput plugin to our joystick
    probably not really hard, but we didn't have experience with it
    pro: 
    - we can implement faster the previous version
    of the controller to this python program
    - this program handle the obstacle detection data, probably
    this is the best place to implement collision avoidance 
    - we can remote control the robot without unreal engine
    with the collision detection

    cons:
    -  if we want to test out new remote control solutions,
    we have to program it from scratch with python
    - currently it's a separate program, we have to
    implement it in the EssortRobotController
    - it's harder to simulate, and test out the program
    - probably for the walking in VR remote control we have to
    implement the unreal engine remote controller anyway
    because the VR controller data is already available at the
    unreal engine side 

    At now it looks like we will implement both solution in the future, but first we will probably implement the EssortRobotController one. We will decide it in the upcoming weeks.

  • Documenting the working principle

    BTom03/28/2021 at 15:54 0 comments

    The TCP socket connection working between the current version of the unreal engine and the new robot control program. Thanks to this plugin: https://github.com/CodeSpartan/UE4TcpSocketPlugin

    At software side we are experimenting the new TPS view concept, and implementing the Bástya 1.5 features to this version of the robot.


    We made two explanatory illustrations about the communication protocol, head, and robot movement. 

    Communication from PC to the robot
    Robot movement direction

  • New parts and current tasks

    BTom03/21/2021 at 10:26 2 comments

    We updated our part list with the additional components, refreshed the B6 profile part numbers.

    Currently we are working on the extension of the chassis. We build two more level on the robot. 

    The first one in the future will contains the lift mechanic. It will rise the eye height of the robot. But this isn't needed for the opencv competition so we will return to it later.

    The second stage is where we put the electronics, and the OAK-D cameras. We will put the robot head on top of this satage. The new head will be in another project log. Approximately the top of the robot 1 meter above ground.

    In previous weeks we received  the OAK-D cameras, Mikrotik routers, and the RPI boards. 

    OAK-D cameras

    The robot controller board is ready to be installed too. There will be more information about it later.

    Essort robot contoller board

    At last but not the least this is the first version of the data flow schematic of the robot. 

    Bástya 2 - "Obelisk" data flow schematic

  • #OAK2021 - Phase 2

    BTom03/06/2021 at 13:39 0 comments

    We was chosen as a Phase 1 Winner in OpenCV AI Kit 2021!  All the winners are listed on the official competition page at https://opencv.org/opencv-ai-competition-2021/#phase1-winners-list

    Our plan is to put OAK-D cameras on the robot to implement obstacle detection and pose estimation. When users remote control the platform, currently they see first person view and they are not aware if there are other people or objects around them.

    With the pose estimation waving can be recognized thus the robot can automatically turn towards them and start automagically interacting with them.


    We will display the additional data in VR. The remote controlling user will be able to switch between FPS, and TPS view.

    In the following 3 months we will be documenting the process here.

  • The new wheels (why we bought it, and didn't build it)

    BTom10/20/2019 at 10:16 0 comments

    In this robot, we need a wheel with much higher carrying capacity than the previous wheels we used.
    In the Bastya 1 we used WEX omni wheel: 4" Omni-Directional ( https://www.vexrobotics.com/edr-wheels.html )

    The first ide was that, we will build omniballs for the wheels: ( https://www.youtube.com/watch?v=ZOCdI2gzMqI )  It looks like simple and much higher carrying capacity.

    We used this for reference:

    The first version:

    It consist hamster ball and laser cut plastic sheets. We can't find the required sized ball. (in this picture, the wheel bearing placement isn't completed )

    The next versions is fully 3D printed:

    It came out it isn't have enough carrying capacity (probably it can be fixed with more thicker walls). On the other side of the hemisphere we need too put something to rotate. In the small models its a small ball. (our first plan was that if we disassemble some old PC mouse we can use the ball, and the mechanic parts to hold in place. When we examine the size of the 3D printed hemisphere, and the size of the robot, we thought it will be too weak.

    After that we found out another version of the omni ball used in the Pepper robot.

    So with this reference we started to design our version of it:

    When we calculated the price of this version, and the necessary machining of the parts, we thought it will be better if we stick with the omni wheel what we used previously in lots of robots:

    The next idea was we will build the omni wheel:

    We thought we can build an omni wheel easily, but after lots of experiments, it looks like it isn't a trivial task. In small scale we already built omni wheels with 3D printed. The bigger wheel we designed for this robot consists of aluminium and rubber wheels. The aluminium part easily can be made with CNC machine. And the rubber wheels contains a 3D printed reinforced core. We thought it is a solid plan, and thought with some experiments we can make high carrying capacity wheels cheaply with the 3D printed rubber rollers. 

    (spoiler alert: it came out it's much more expensive in the end, without counting the time we put in it. But we learnt a lot from it)

    So in details:

    First we designed the wheel, and the rollers:

    We looked around about the heavy duty omni wheels and it looks like with bigger roller is the better. So we went that way with the planning.

    After that we designed the core of the rollers. First idea was that, if we can mold it with 2 component rubber, we can adjust the flexibility, and hardness. The reinforced core contains the axle, and with the 3D printed core, we thought it will not cut the rubber when we put weight on it.

    These is the variations for the roller core:

    The first one, is designed with the concept of weight distribution with a grid: (it was fun to learn how to make shape like this in the CAD program :) )

    It came out of the printer so dense we can't mold it.

    The second version contains less columns and with new grid distribution: (8, 6, 4 columns with 2 directions)

    This version is possible to use in the mold, but when it came out of the printer it was too brittle.

    The next version contains more rigid 3D printed object.

    With this version we made some test molds. We designed a reusable mold. The core is fixed in the center with an axle.

    It came out looking good, but when we put weight on it. It crushed the 3D printed core.

    Another problem we found out in the first tests we can't variate the flexibility easily. We thought we need a vacuum chamber for this.

    The next idea was that if we can make the rolleres with lathe from some material it will be better, and cheaper. We found out that the plastic what is used in these rollers are not cheap (and didn't have lathe, so we have to order the rollers) 

    After this we made some calculations and looked like it is cheaper to buy the wheels :)

    Finally we ordered the wheels:...

    Read more »

  • first "steps" (testing the chassis)

    BTom10/05/2019 at 12:56 0 comments

    We designed the chassis for the omni ball:

    Later we changed the plans and now we are finally using omni wheels:

    Currently it can be remote controlled with arduinos to test the mechanical structure.

    It's a simple setup, with HC-12 moduls. We reused our example project, what we used in a competition https://github.com/Essort/MaM2018 (its for the competition teams, so it isn't in English, but if needed I can translate it)

    In the originals plans we used 26650 3.7V 5000mAh battery cells. But we had an opportunity to use Toyota Prius Hybrid Battery Cells, so we currently placed 6 in the robot. (for the testing we only use 3) 

    For the prolonged testing we will connect it to a power supply.

    The result of the first test is, we need to reinforce the stepper motor mounting. And maybe we will change the GT2 belts to a bigger ones.

    Currently the robot can be used like a remote controlled table :)

View all 7 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