-
Notifications
You must be signed in to change notification settings - Fork 58
Rosserial Integration #111
Comments
Some additional summary of our initial discussion @Octogonapus: Design of Adaptation Layer as Registry / Class WrappersThere are a few ways to make some sort of adaptation layer for rosserial bindings ontop of the OkapiLib classes. 1 - Create a registry class that accepts OkapiLib objects.The registry class assigns the required publishers/subscribers to track the OkapiLib with publishers and subscriber callbacks. The registry would presumably have an overridden method for "register" for each supported OkapiLib class that would be the mechanism for writing the ROS binding behavior. rosserial::Registry rosManager;
void opcontrol(void) {
// set up loop thread to publish sensor data from all registered objects
rosManager.start(20);
// Normal OkapiLib object definition
// ...
okapi::ChasisController chassis(model);
// ...
// every 20 milliseconds, sensor array published on topic , e.g. "/myDrive/sensors/"
// AND subscriber callbacks are set for another topic, e.g. "myDrive/cmd_vel/"
// Note: these names are all just placeholders
rosManager.register(chassis, "myDrive");
// the above requires implementation of
// void rosserial::Registry::register(okapi::ChassisController, const char*);
// AND
// void rosserial::Registry::ChassisControllerCallback(const geometry_msgs::Twist&);
}
1 PROS (no pun intended):
1 CONS
2 - Create rosserial subclasses of OkapiLib objects.There would be one subclass for every supported OkapiLib class that extends the original with the ROS functionality. void opcontrol(void) {
// Normal OkapiLib object definition
okapi::ChasisController chassis(model);
// every 20 milliseconds, sensor array published on topic , e.g. "/myDrive/sensors/"
// AND subscriber callbacks are set for another topic, e.g. "myDrive/cmd_vel/"
rosserial::wrappers::ChassisController rosChassis(chassis, "myDrive");
// the class has the pub/sub logic from before, but in the class
} 2 PROS:
2 CONS:
These approaches are similar in nature, after all. I think that the first way has a cleaner interface. Configuration for Registered objectsWhen an OkapiLib object is registered, additional configuration should be provided.
Additional notesThis architecture makes it very straightforward how to handle the API: every supported object has a corresponding |
As I had said before, I prefer the first option. Others are welcome to share their opinions. |
Is your feature request related to a problem? Please describe.
Problem: Integrating a ROS serial connection with VEX hardware is possible with rosserial for V5 alone, but requires user configuration for lots of hardware-specific setup, such as setting up publishers for sensor data, moving the robot based on commands, etc...
Describe the solution you'd like
The OkapiLib API can act as a schema for mapping ROS objects into abstractions, e.g. chassis, that ROS can control via standardized ROS messages, e.g. Twist command velocity messages for that chassis.
Describe alternatives you've considered
Using rosserial with vex hardware is still possible (example), but the OkapiLib abstractions can provide control systems built-in, which will allow the ROS messages to be a more intelligent control interface, with minimal user requirement.
Versions
PROS: 3.0.6
OkapiLib: recent
Additional context
This issue is intended to be a running discussion about integrating rosserial and OkapiLib.
The text was updated successfully, but these errors were encountered: