ros_control and robots without joints/actuators/transmissions about ros_control HOT 4 CLOSED

Ya, that sounds right, and your application looks like a good match for this stack.

Good luck!

from ros_control.

I didn't quite understand the "robots without joints/actuators/transmissions" part of the title. For a quadrotor you would at least expose the four propelling rotors as joints, right?, or does the hardware driver only expose a high level controller that operates in Cartesian space?. At any rate you should expose a set of joints, and optionally make transmissions and actuators explicit if this is required by your hardware setup.

from ros_control.

Well, I wasn't planning on exposing the four propelling rotors as joints because it didn't seem appropriate to describe them as joints since they would be fixed. Likewise, the use of a transmission or actuator didn't seem appropriate for a quadrotor application as well. But, I probably have a poor understand/application of the terminology (and how the terminology applies to aerial vehicles in general). My thought was to create a hardware interface for the Electronic Speed Controllers, IMU, etc, and create a controller that would operate in Cartesian Space, like you mentioned, for control of the yaw/pitch/roll of the quadrotor. It made sense in my head, but maybe I need a few more pieces (joints/transmissions/actuators) to fully implement the control system.

from ros_control.

If the Electronic Speed Controllers control the rotor speeds, you can model rotors as velocity-controlled joints. A rotor interacting with the air is not that different from a wheel interacting with the ground. I don't know about aerial robots, but for wheeled robots, wheels are explicitly modeled as joints.

from ros_control.