Fmilano/cpt pointlaser ee poses visitor #110
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change "between... and" to "from... to"
- Make it clear that `initial_pose` used to initialize the optimizer is the pose from arm base to reference link; - Make it clear that the "pose-prior" term optionally added to the optimization is over the model offset (marker pose w.r.t. arm base).
To clarify meaning of the returned pose.
Private members for the noise pose priors.
Now there is no notion of mode: the service handler does not get directly called, but can only be executed through a service call. The service call fails with a warning - and the HAL routine does not get executed - if the initial pose to which the arm should be set is not received.
For clarity.
The task execution for the demo is handled in a different module; the HAL node should just output the corrected base pose.
If required, such a service should be implemented in the future; the pose to check is already computed.
In preparation for new service with different signature to be used in the new demo.
Now the service returns the robot-base pose as the service response, rather than calling a separate service to directly make the controller to update it. The placeholder to check for the correct update of the base pose is removed accordingly, since the update now happens after the HAL service has completed.
Forgotten from 0bf71a1.
No longer needed, as the task triggering has been decoupled from the HAL module and all communication is done through ROS messages that are handled by other modules. Still need to implement the communication to trigger the arm movement.
A message is now published with a path from the start to the target pose of the end-effector, in the robot base frame. NOTE: currently, both the motion duration and the time the module waits after triggering the task execution are hard-coded.
Set the right source code for the MABI-localizer node.
As a consequence, the node/localizer for the old demo (Kinova arm) is disabled.
It is now assumed that when the HAL routine gets triggered, the arm is already in its initial pose. The latter is separately handled by the state machine.
The movements are now handled separately by the state machine. Note: this is a temporary commit, in a future version a separate service will be implemented to be called in order to take/add measurements after each movement of the routine.
For clarity.
Instead of `world` it should be `map`.
It is actually the robot-base pose in the map frame, rather than the end-effector pose in the base frame.
To make sure the right version of all the packages is used.
To avoid overriding `cpt_selective_icp` functionalities if merging to `master`.
For back-compatibility: original `cpt_selective_icp` package was publishing scanner-to-map transforms, but HAL routine needs map-to-scanner transform.
|
Test FAILed. |
1 similar comment
|
Test FAILed. |
To allow jenkins to clone the repo.
|
Test FAILed. |
2 similar comments
|
Test FAILed. |
|
Test FAILed. |
From packages in the `dependencies.rosinstall` file of multiple packages, to avoid Jenkins conflicts (would compile fine locally).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Big PR that adds all the functionalities to run the HAL routine with current setup. I consider
cpt_pointlaser_locas the base branch for the HAL routine that I would eventually like to merge to master, but I'm settingcpt_pointlaser_loc_localizeras the base branch here because there is an old PR (#101) that is still open and which adds some basic ROS interface that has not been reviewed yet. #101 should be nothing major (I was just porting the old repo and refactoring), and I performed all the final tests with this branch.The README here contains the instructions to build the stack, and to set up and reproduce the test.
The main changes in this PR are:
cpt_pointlaser_ctrl_roscpt_pointlaser_loc#101, now I added the following packages:cpt_pointlaser_common: contains a config file with common parameters and util functions.cpt_pointlaser_ctrl_ros: see above.cpt_pointlaser_hal: contains a node and two launch files that facilitate running the whole routine in a state-machine-like fashion (cf. README). Following the instructions in the README, the user can execute the whole routine just by writingreadymultiple times to move from one step to the subsequent one.cpt_pointlaser_msgs: Contains all the custom-defined messages/services, so that if an external package needs to use just the latter, it doesn't have to depend on the other packages.cpt_selective_icpso that the map-to-scanner transform, rather than scanner-to-map, gets appended to the TF tree. This is needed in the HAL routine so that the TF trees of the robot and of the building model are not disconnected. A parameter is added to theMapperParametersto ensure back-compatibility with the previous version ofcpt_selective_icp.NOTE (still TODO): The laser extrinsics are not the real ones, and will need to be updated when a new URDF is available. Now, the pointlaser-frame origin is assumed to coincide with the end-effector frame, and I rotated the pointlaser transforms from the previous file to make them match the orientation of the lasers with these "wrong" extrinsics.