Unsure about project nodes and communication between nodes

Question

Hi!

I'm pretty new to ROS (Robot Operating System). I've done quite a few tutorials and I'm starting to get a grasp of it. Right now, I'm looking to build my own little project to really get a better understanding of the way it works.

I'm trying to build a fully autonomous Rubik cube solving robot. However, I'm not quite sure I fully understand what kind of nodes I'd need and how to make them communicate with each other. Here's the structure I'm thinking about:

• Node for the running camera. Outputs color images.
• Node for the servo motors (turns the Rubik Cube). Input is a sequence of moves to solve the cube. Using an Arduino.
• Node with the main Python code. This is the part I'm not quite sure about.

The Python code node works like this:

1. Subscribes to the camera, takes the 1st image, saves it as cube face #1.
2. Publishes a signal to the servos to rotate the cube.
3. Repeats steps 1 and 2 until all 6 faces have been saved.
4. Process saved faces to obtain current cube configuration (associates a color to every position)
5. Finds a solution for the Rubik cube.
6. Publishes the sequence of moves to the Arduino

Is this the right way to do things? Should I change the structure? Also, I'm not quite sure I understand how the publishing/subscribing will work considering the nodes will be sending messages back and forth. I have already implemented the Python code (without the subscribing/publishing) - However, I don't really understand how to add it to a node.

I'm really eager to learn so please do not hesitate to point me in the right direction, or to point me towards a good read or similar example. In particular, any example where two nodes communicate back and forth and waiting for a signal before executing part of the code would be appreciated!

---

Originally posted by gadese on ROS Answers with karma: 13 on 2019-02-28

Post score: 1

Answer 1

You don't need video. I think you'd be better off with one still image. I would implement the "camera" as a service. It would return one frame on request.

Your mechanical system of motors and holders is likely complex. It seems to me that there are six ways to hold a cube and once held you can either turn the entire cube or just one layer. I think you would want to break this down into at least two nodes One does low-level motor control and one does logical operations. The top-level node would only run when called but the low-level servo controller might need to run continuously. (I don't know if these are DC servo motors or hobby type servos)

published and subscribed messages may not be what you want. Perhaps the camera and the cube mover need to be services. the main program tells the service what to do. and it is done.

I don't see the cube solver as a machine that operates continuously, but rather as a machine that moves in steps, so maybe services?

---

Originally posted by chrisalbertson with karma: 136 on 2019-02-28

This answer was ACCEPTED on the original site

Post score: 1