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
I am new to Autoware, and I am trying running a demo (based on the Planning Simulation one) where the Autoware framework nodes are distributed among 2 hosts on the same network, precisely:
a workstation running all the components, except for the control node, and
an embedded board running the control node only.
Description of the problem:
After having placed the vehicle and generated the trajectory to a target point in the map, the "Auto" button which should enable the automatic trajectory following is grayed out and the vehicle remains in a "stop" condition.
Details
I am running the containerized version of Autoware on both the hosts: the workstation is using the nvidia/cuda enabled docker image, whilst the embedded board is running the container based on the docker image without nvidia/cuda.
Inspecting the launch files, I saw that the control part is managed by the "launch_control" argument in the autoware.launch.xml, which leads to the inclusion of the tier4_control_component.launch.xml.
For this reason, on the embedded board, I prepared a launch file which supplies that component only, precisely:
On the Workstation, the core part launching the Autoware framework is something like (the "launch_control" variable enable or disable the inclusion of the control launch file):
Start Autoware:
1a. Start Autoware with all the main nodes (without the control node) on the workstation
1b. Start the control node on the embedded board
Place the vehicle on the map
Assign a 2D target and wait for the plan to be generated and visible on the map
Press the "Auto" button to let Autoware drive the simulated vehicle along the planned path.
When the control node is spawned on the embedded board , I cannot accomplish the step 4.
Debugging Attempt:
Everything runs perfectly on the workstation when the control node is spawned on the same machine running the Autoware framework (by enabling the inclusion of the tier4_control_components.xml and skipping the step 1b).
I disabled the firewall on both the machines to be sure that it was not a communication issue;
I checked that I can see the ros2 nodes and topics coming from the other machine (the workstation sees the ros2 components on the embedded board and vice-versa);
I am able to see the ros2 nodes and topics flowing on the shared network;
Following some discussions found online, where the "Auto" button was locked as it is in my case, I tried to gather further information running rqt and visualizing the graph debugger: I noticed that there is something wrong with the control node but I am not able to understand where is the problem.
I suspect I am doing something stupid somewhere in the setup...but I am still trying to figure it out. Any help from experienced users will be very appreciated.
I attach the log recorded on the Workstation (ws.log) and the one recorded on the embedded board (embedded.log).
I also attach the full launch files I am using to run the demo: Workstation side (ws.launch.txt) and Embedded board side (ctrl.launch.txt). I also attach a screenshot with the output of the rqt tool.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am new to Autoware, and I am trying running a demo (based on the Planning Simulation one) where the Autoware framework nodes are distributed among 2 hosts on the same network, precisely:
Description of the problem:
After having placed the vehicle and generated the trajectory to a target point in the map, the "Auto" button which should enable the automatic trajectory following is grayed out and the vehicle remains in a "stop" condition.
Details
I am running the containerized version of Autoware on both the hosts: the workstation is using the nvidia/cuda enabled docker image, whilst the embedded board is running the container based on the docker image without nvidia/cuda.
Inspecting the launch files, I saw that the control part is managed by the "launch_control" argument in the
autoware.launch.xml
, which leads to the inclusion of thetier4_control_component.launch.xml
.For this reason, on the embedded board, I prepared a launch file which supplies that component only, precisely:
On the Workstation, the core part launching the Autoware framework is something like (the "launch_control" variable enable or disable the inclusion of the control launch file):
Step Followed to launch the experiment
I am doing the following:
1a. Start Autoware with all the main nodes (without the control node) on the workstation
1b. Start the control node on the embedded board
When the control node is spawned on the embedded board , I cannot accomplish the step 4.
Debugging Attempt:
tier4_control_components.xml
and skipping the step 1b).Following some discussions found online, where the "Auto" button was locked as it is in my case, I tried to gather further information running rqt and visualizing the graph debugger: I noticed that there is something wrong with the control node but I am not able to understand where is the problem.
I suspect I am doing something stupid somewhere in the setup...but I am still trying to figure it out. Any help from experienced users will be very appreciated.
I attach the log recorded on the Workstation (ws.log) and the one recorded on the embedded board (embedded.log).
I also attach the full launch files I am using to run the demo: Workstation side (ws.launch.txt) and Embedded board side (ctrl.launch.txt). I also attach a screenshot with the output of the rqt tool.
ctrl.launch.txt
ws.launch.txt
ws.log
embedded.log
Best Regards
Beta Was this translation helpful? Give feedback.
All reactions