Overhaul motor support with motor groups about sights HOT 4 OPEN

Here's my proposal for a new motor config schema:

{
  "motors": {
    "connections": [
      {
        "uid": "dynamixel_01",
        "type": "dynamixel",
        "port": "/dev/ttyACM0",
        "baudrate": 9600,
        "motors": [
          {
            "guid": "drive_left_front",
            "dynamixel_id": 1,
            "class": "AX12A",
            "name": "Drive Left Front"
          },
          {
            "guid": "drive_left_back",
            "dynamixel_id": 2,
            "class": "AX12A",
            "name": "Drive Left Back"
          },
          {
            "guid": "drive_right_front",
            "dynamixel_id": 3,
            "class": "AX12A",
            "name": "Drive Right Front"
          },
          {
            "guid": "drive_right_back",
            "dynamixel_id": 4,
            "class": "AX12A",
            "name": "Drive Right Back"
          }
        ]
      },
      {
        "uid": "sabertooth_01",
        "type": "sabertooth",
        "port": "/dev/ttyACM1",
        "baudrate": 9600,
        "motors": [
          {
            "guid": "shoulder_1",
            "channel": 1,
            "name": "Shoulder 1",
            "limit": 160
          },
          {
            "guid": "shoulder_2",
            "channel": 2,
            "name": "Shoulder 2",
            "limit": 160
          },
          {
            "guid": "elbow",
            "channel": 3,
            "name": "Elbow"
          },
          {
            "guid": "wrist_pitch",
            "channel": 4,
            "name": "Wrist (Pitch)"
          },
          {
            "guid": "wrist_roll",
            "channel": 5,
            "name": "Wrist (Roll)"
          }
        ]
      },
      {
        "uid": "pololu_01",
        "type": "pololu",
        "port": "/dev/ttyACM2",
        "baudrate": 9600,
        "motors": [
          {
            "guid": "paddles",
            "channel": 01,
            "name": "Paddles"
          }
        ]
      }
    ],
    "groups": {
      "drive_left": [
        "drive_left_front",
        "drive_left_back"
      ],
      "drive_right": [
        "drive_left_front",
        "drive_left_back"
      ],
      "paddles": [
        "paddles"
      ],
      "shoulder": [
        "shoulder_1",
        "shoulder_2"
      ],
      "elbow": [
        "elbow"
      ]
    }
  }
}

I think this should encompass most use cases as it allows for:

• a mix of different types of motors (eg. DC motors for wheels and Dynamixels for the arm)
• multiple connections of the same type (eg. multiple Sabertooth motor controllers)
• flexible and easily reconfigurable groups
• mix of motor types within groups
• easy support for a new type of motor connection
• mix of different 'classes' of motors (i.e. Dynamixel AX and XL series are both supported together)
• easy support for per-motor configuration (useful for setting rotation limits, etc.)

I'm open to feedback and suggestions

from sights.

Regarding the implementation, this is what I'm thinking:

• motor plugins are loaded as usual, but now each plugin requires a connection and an additional motor object class
  • e.g. SabertoothConnection and SabertoothMotor
• The MotorHandler creates the motor connection handlers from the configuration file. Likely stored in a dictionary with their UID as the key.
• It then creates the individual motor objects which each contain a reference to their connection handler (Note that two Dynamixel servos won't necessarily have the same handler).
• Each motor is appended to an accessible dictionary motors within MotorHandler which manages controlling each of these motors. The GUID acts as the key.
• Groups are then loaded, these should just basically be loaded as they are in the JSON file above, into a variable called groups and then lookups can be done whenever we need.

So this means the main usage will be like this:
To move a single motor, from within MotorHandler, we can do:

motors["wrist_roll"].set_speed(100)

To move a group we can do:

for motor in groups["drive_left"]
	motors[motor].set_speed(100)

But I would like to additionally propose a shorthand method of doing this:

groups["drive_left"].set_speed(100)

How exactly that is implemented is open for discussion.

Each individual motor class handles it's own speed formulas, how it communicates with the connection handler etc.

Basically this means the end user can treat each motor the same, when they want to at least. Each motor will expose a similar set of functions, such as set_speed() or get_position() where applicable.

from sights.

Hijacking this issue for its motor discussion.

Here are some more thoughts on motor groups:

• Only allow a motor to exist in one group at a time?
  • This protects the user from stupid things but there may be useful ways to put one motor in multiple groups. I haven't thought of any yet though.
• Allow the user to define rotation limits (if necessary) for each motor group
• Allow the user to set a keyboard key (non-exclusive) to rotate the motor group in one direction
• Allow the user to set another keyboard key (again, non-exclusive but not the same as the same group in the previous direction) to rotate the motor group in the opposite direction
• Allow the user to link each motor group to a speed changing module
  • It's basically the speed changing module we already have, except modular
  • Allow the user to set a (unique) speed up and speed down key for each speed change module
• Each motor uses a wrapper specific to the type of motor that implements standard functions to control a single motor
• When a command is sent to a motor group, those functions are called for each motor in the group

from sights.

RE: Only allow a motor to exist in one group at a time?

After some consideration I think it would be useful to allow any one motor to exist in multiple motor groups. This would allow for more flexibility creating controls (#91).

As an example, we have the three motor groups:

motor_group_left_side:
    motor_front_left
    motor_rear_left

motor_group_right_side:
    motor_front_right
    motor_rear_right

motor_group_rear:
    motor_rear_left
    motor_rear_right

And key press functions:

onKeyPress('A'):  //Turn left
    motor_group_left_side.go_forward()
    motor_group_right_side.go_backward()

onKeyPress('R'):  //Rear wheel drive
    motor_group_rear.go_forward()

Of course, this is configured graphically in the Sights Design Wizard 2.0.

Now, as a point of discussion... Why have motor groups at all? Why not:

onKeyPress('A'):  //Turn left
    motor_front_left.go_forward()
    motor_rear_left.go_forward()
    motor_front_right.go_backward()
    motor_rear_right.go_backward()

onKeyPress('R'):  //Rear wheel drive
    motor_rear_left.go_forward()
    motor_rear_right.go_forward()

from sights.