Vector Driver - gregory-j-r/Anki-Vector-ROS2 GitHub Wiki

How to Make with Ros2

The previously made Vector Driver, made with Ros, was not able to accommodate the driving of 2 or more robots at the same time. A Ros2 version however would be able too. A rough Driver was created to test the functionality and viability of controlling 2 Anki Vector robots in parallel. It was shown that using Ros2 to control 2 Vector robots simultaneously did not pose any additional latency or bandwidth problems, and is very viable. The rough driver made is merely a first pass, and is not viable for use in a larger distribution type environment. However I will lay out the “blueprints” for what I believe would make an effective driver. The table in the section Anki Vector and Python SDK may be helpful for this part as it goes through most of the needed functionality of the driver.

Establishing the Connection

To start off, the Anki Vector robot needs to establish a connection. The driver should be able to accept the serial number of a robot, establish a connection, and send back a confirmation that the connection was established. A Ros2 service is perfect for this, and should take a String as the request message type and a Bool as the return message type. It is also important that whatever machine is running the Driver should also have all the .ini and .cert files saved as they are needed to establish connections with the robots. The serial numbers of the robots should be then used to create a set of nodes with names including the serial number. For example, if robot with serial number 1234abcd had a connection request then the Gyro publisher topic for that robot could be Gyro_1234abcd.

Actuators and Sensors

Head Motor

  • Set head angle - This node should subscribe to a topic whose messages consist of a float between -22.0 and 45 (head angle)
  • Get head angle - This node should publish the raw Head Angle value to a topic
  • Set head speed - This node should subscribe to a topic whose messages consist of a float (head speed)

Lift Motor:

  • Set lift height - This node should subscribe to a topic whose messages consist of a float between 0 and 1 (lift height)
  • Get lift height - This node should publish the raw Lift Height value to a topic
  • Set lift speed - This node should subscribe to a topic whose messages consist of a float (lift speed)

Wheel Motors

  • Set wheel speeds - This node should subscribe to a topic which has messages consisting of tuples (left wheel speed, right wheel speed). (alternatively could use cmd_vel)

Pose

  • Set robots pose
  • Get robots pose - This node should publish the Pose of the robot to a topic as an array

Laser Range Sensor

  • Get laser raw value - This node should publish the raw Laser Range Finder value to a topic

Speakers

  • Be able to pass a string to say - A service that should take a String and should return a boolean confirmation of if the message was spoken by the robot

Face Screen

  • Set face image - A service that should take an image and should return a boolean confirmation of if the image was successfully put on the screen

Floor Sensors

  • Get if cliff detected - This node should publish the boolean value received from the robots cliff detectors

Capacitive Back

  • Get raw value - This node should publish the raw Capacitor value to a topic

Accelerometer

  • Get raw value - This node should publish the raw Accelerometer value to a topic

Gyro

  • Get raw value - This node should publish the raw Gyro value to a topic

Camera

  • Get raw image - This node should publish the raw camera image to a topic

Events

A node is needed to publish event data to a topic. Event data that is most pertinent is:

  • Cube, Charger, or Custom symbol location and Bounding box information
  • Cube, Charger, or Custom symbol Pose

Visible Objects

A node is needed to publish the list of objects visible by the robot. It should publish a list of Strings to a topic containing all visible objects and custom objects.

Behavior Requests

Vector has many built in behavior functions. These include but are not limited to: go_to_pose(), dock_with_cube, drive_off_charger, etc. A Service node should be set up that can accept requests to execute these actions (perhaps have the requests be integers or strings that map to different actions, and have a help command that maps to a list of the different mappings).