05/02/2021 at 00:09 •
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 .
04/17/2021 at 12:46 •
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.
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
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 engine The 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
- 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.
- we have to use RawInput plugin to our joystick
probably not really hard, but we didn't have experience with it
- 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
- 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.
03/28/2021 at 15:54 •
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.
03/21/2021 at 10:26 •
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.
The robot controller board is ready to be installed too. There will be more information about it later.
At last but not the least this is the first version of the data flow schematic of the robot.
03/06/2021 at 13:39 •
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.
10/20/2019 at 10:16 •
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:
It isn't cheap, but it's a matter of perspective. We can't build one cheaper with this parameters.
10/05/2019 at 12:56 •
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 :)