New parts arrived, and the head mechanics nearly completed

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

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

Progress in the past weeks

Discussions

Become a Hackaday.io Member