You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Added extra documentation
---------
Signed-off-by: Max Waterhout <max.waterhout@soprasteria.com>
Signed-off-by: Jelmer de Wolde <jelmer.de.wolde@alliander.com>
Signed-off-by: Max Waterhout <max.waterhout@hotmail.nl>
Co-authored-by: Max Waterhout <max.waterhout@soprasteria.com>
Co-authored-by: Jelmer de Wolde <jelmer.de.wolde@alliander.com>
Copy file name to clipboardExpand all lines: docs/content/conventions/conventions.md
+56-5Lines changed: 56 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,9 +4,13 @@ SPDX-FileCopyrightText: Alliander N. V.
4
4
SPDX-License-Identifier: Apache-2.0
5
5
-->
6
6
7
-
# ros_package conventions
7
+
# Conventions
8
8
9
-
## Folder Structure
9
+
## ROS packages
10
+
11
+
ROS packages are defined in the *ros2_ws/src* directory.
12
+
13
+
### Folder Structure
10
14
11
15
We try to follow this folder structure for the ROS packages:
12
16
@@ -28,7 +32,14 @@ ros_package/
28
32
└───ros_package/
29
33
| | __init__.py
30
34
| | py_module.py
31
-
|
35
+
│ └── test/
36
+
│ ├── conftest.py
37
+
│ ├── unit/
38
+
│ │ └── test_py_module.py
39
+
│ ├── integration/
40
+
│ │ └── test_service_client.py
41
+
│ └── end_to_end/
42
+
│ └── test_full_launch.py
32
43
└───launch/
33
44
| launch_file.launch.py
34
45
```
@@ -39,8 +50,15 @@ ros_package/
39
50
- A sub-directory `ros_package/` with the same name as the ROS package can be used to create a Python package. This directory contains an `__init__.py` file and the Python modules of the Python package.
40
51
- Possible launch files are located in the `launch/` directory.
41
52
- More directories are possible, like `urdf/` for urdf files or `config/` for config files.
53
+
- The testing layout is placed alongside the Python package, with these subfolders:
42
54
43
-
## CMakeLists.txt
55
+
-`unit/` for fast, logic-only tests
56
+
-`integration/` for multi-component or ROS client/server tests
57
+
-`end_to_end/` for full launch/simulation tests
58
+
59
+
Use a top-level `test/conftest.py` to define shared fixtures, and name your files/functions `test_*` so pytest auto-discovers them. The most general fixtures are defined in the `conftest.py` in the root of the repository.
60
+
61
+
### CMakeLists.txt
44
62
45
63
This CMakeLists.txt file shows the different parts required to build a ROS package:
46
64
@@ -70,7 +88,7 @@ All shared folders are installed into the share directory. This includes the dir
70
88
**39-45**:\
71
89
The file always ends with a default test and the *ament_package()* command.
72
90
73
-
## package.xml
91
+
###package.xml
74
92
75
93
The package.xml file is related to the CMakeLists.txt file:
76
94
@@ -93,3 +111,36 @@ Next, we define other packages where our package depends on.
93
111
94
112
**23-28**:\
95
113
The file ends with the default test dependency and an export definition.
114
+
115
+
### Custom messages, services and actions
116
+
117
+
We define custom messages, services and actions in our *rcdt_messages* package. This package has the following folder structure:
118
+
119
+
```text
120
+
ros_package/
121
+
| CMakeLists.txt
122
+
| package.xml
123
+
|
124
+
└───msg/
125
+
| | custom_message_definition.msg
126
+
|
127
+
└───srv/
128
+
| | custom_service_definition.srv
129
+
|
130
+
└───action/
131
+
| custom_action_definition.action
132
+
```
133
+
134
+
In the CMake file, we automatically look for all msg, srv and action files and generate interfaces for them:
This page gives some background of the usage of our Franka-related packages.
10
-
All software is based on the [Franka Emika Research](https://franka.de/products), based on the [Franka Control Interface](https://frankaemika.github.io/docs/overview.html)
9
+
This page gives information about usage of the Franka Research 3.
11
10
12
-
## Quickstart robot in simulation
11
+
## Physical robot
13
12
14
-
To start the simulation, run in 2 separate terminals:
13
+
The physical robot can be started programmatically or manually.
Running the brick pickup demo can be done in the same way.
39
+
This should launch Rviz and show the state of the robot.
55
40
41
+
You can control the robot using a connected gamepad or using the *MotionPlanning* plugin in Rviz.
56
42
57
-
##Setup & FCI activation of physical robot
43
+
### Quick start (programmatic)
58
44
59
-
### Programmatic unlock via `.env`
60
-
61
-
You can unlock the robot automatically without using the browser by setting environment variables in a `.env` file at the root of your workspace:
45
+
You can also unlock and activate the FCI entirely from the command line by dropping a `.env` file in your workspace root:
62
46
63
47
```dotenv
64
48
# .env
65
49
FRANKA_HOSTNAME=your-hostname
66
50
FRANKA_USERNAME=your-username
67
51
FRANKA_PASSWORD=your-password
68
-
```
52
+
````
69
53
70
-
When you run the launch command, the robot will automatically unlock and activate the FCI.
54
+
This functionallity is based on [jk-ethz/franka\_lock\_unlock](https://github.com/jk-ethz/franka_lock_unlock).
55
+
With our fork with robot-specific enhancements: [https://github.com/alliander-opensource/franka\_lock\_unlock.git](https://github.com/alliander-opensource/franka_lock_unlock.git)
71
56
72
-
This feature is based on the [jk-ethz/franka\_lock\_unlock](https://github.com/jk-ethz/franka_lock_unlock) repository. We maintain a fork with specific enhancements for our robot at [alliander-opensource/franka\_lock\_unlock](https://github.com/alliander-opensource/franka_lock_unlock.git).
You can also manually lock the robot via the web interface, plug an Ethernet cable from your laptop into the control box’s LAN port (this is not the LAN port on the arm itself). Additionally, change your Ethernet IPv4 settings to **Manual**and set the following:
63
+
the robot will automatically unlock and activate the FCI.
77
64
78
-
```text
79
-
Address: 172.16.0.1
80
-
Netmask: 255.255.255.0
81
-
```
65
+
## Simulation
82
66
83
-
67
+
You can also start a simulation, without requiring a real Franka arm. Use the same launch file, but this time without the *simulation* flag:
84
68
85
-
You may also want to consider making this a separate profile for future convenience when moving to different networks.
69
+
```bash
70
+
ros2 launch rcdt_franka franka.launch.py
71
+
```
86
72
87
-
If the robot's power switch is turned on, you should now be able to go to [https://172.16.0.2](https://172.16.0.2).
88
-
Fill in the username and password, and click **Unlock**. After that, click **My Franka Robot → Activate FCI**. The robot is now ready to be controlled by the user, and the commands in Quickstart can be run.
The **Mobile Manipulator** combines the Husarion Panther base with the Franka Emika arm in a fully modular stack. By treating each as a separate ROS 2 package—`rcdt_panther` and `rcdt_franka`, we can compose them under a new `rcdt_mobile_manipulator` package without duplicating launch or test logic.
10
+
11
+
## Physical robot
12
+
The Franka Emika arm is powered through the battery of the panther and controlled through the build-in computer of the Panther. The controller is connected to the Panther's computer.
13
+
14
+
1. First turn on the Panther and wait till the system is fully booted.
15
+
2. Then run the following command to start the high-voltage system of the panther:
16
+
17
+
```bash
18
+
ros2 service call /panther/hardware/aux_power_enable std_srvs/srv/SetBool "{data: true}"
19
+
```
20
+
3. After that, turn on the Franka arm by flipping the button at the control box.
21
+
4. SSH in the build-in computer and start the combined system within the rcdt_robotics container with:
By exposing the `rcdt_mobile_manipulator` launch description as a pytest fixture, you can **import and run** the existing Panther and Franka end-to-end tests against the combined system without any modification. Any improvements or fixes in the `rcdt_panther` and `rcdt_franka` test suites automatically apply when testing the mobile manipulator, keeping its codebase minimal and focused purely on orchestration.
Copy file name to clipboardExpand all lines: docs/content/moveit.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,9 +29,9 @@ Moveit can be used in different ways. The easiest is to use the MoveGroup interf
29
29
30
30
If more complexity is required, one can also use the C++ API of Moveit. This skips a layer of ROS, which leads to faster performances. Some of the C++ API is also available in the Python API. However, based on our experience, the Python functionalities and documentation are very minimal and we therefore advise to use the MoveGroup interface or the C++ API. More information about the differences can be found [here](https://moveit.picknik.ai/main/doc/examples/examples.html).
31
31
32
-
## How dow we use Moveit?
32
+
## How do we use Moveit?
33
33
34
-
As mentioned before, we make use of the MoveGroup interface. One can start the `move_group` as a ros node of the `moveit_ros_move_group` package. However, the node requires many parameters to start and function correctly. Therefore, we always start the node using the launch file `moveit.launch.py`, located in our package `rcdt_moveit`, where we can easily pass the configuration parameters. Moveit configurations are defined in a separate package, which can be created for a desired robot arm using the [moveit setup assistant](https://moveit.picknik.ai/main/doc/examples/setup_assistant/setup_assistant_tutorial.html). For example, for the Franka robot arm, we created the `rcdt_franka_moveit_config` package. The move_group also requires information about the robot, like joint states. Therefore, the move_group can only be launched correctly while also launching the robot with some required functionalities. One can for example launch a simulation of our Franka robot using, which will by default start a robot simulation and moveit:
34
+
As mentioned before, we make use of the MoveGroup interface. One can start the `move_group` as a ros node of the `moveit_ros_move_group` package. However, the node requires many parameters to start and function correctly. Therefore, we always start the node using the launch file `moveit.launch.py`, located in our package `rcdt_moveit`, where we can easily pass the configuration parameters. Moveit configurations are defined in a separate package, which can be created for a desired robot arm using the [Moveit setup assistant](https://moveit.picknik.ai/main/doc/examples/setup_assistant/setup_assistant_tutorial.html). For example, for the Franka robot arm, we created the `rcdt_franka_moveit_config` package. The move_group also requires information about the robot, like joint states. Therefore, the move_group can only be launched correctly while also launching the robot with some required functionalities. One can for example launch a simulation of our Franka robot using, which will by default start a robot simulation and Moveit:
0 commit comments