Week 2-newSIMprototype

Week 2

• In the last week’s meeting we discussed regarding the errors faced and proposed the solution to solve them. The errors are in this post and the solution and further errors in the week’s post.*

How did I contributed in this week?

After integrating the rotors with the follow_road exercise by changing the web-template scripts including launch.py, there were still errors so we went for this approach:

• As the built new img was not working and the sole purpose of three launch files namely: gazebo.launch, px4.launch, mavros.launch was due to use of PX4. But now while integrating with rotors sim, we don’t need the launch.py along with three separate launch files. So, in the instructions.json script I manipulated the instruction_ros key for launching directly using roslaunch and creating the separate single launch file.

• After getting rid of three separate launch files, the error still continued to come as seen below without & with verbose respectively:

• **Though I was able to launch the files successfully but they weren’t from the browser’s GUI fo the RADI:

• After searching through various pages to solve this error, I stumbled upon the link which failed in the very first error in week 1. That solution led to solving this error.

• Before moving towards the solution let me tell you the non technical thing which I learnt from this: always list all the sources for solving the error as the error changes gradually from one understanding to another so sometimes the old source may come in handy which didn’t seem at first. So, whenever the error changes go & look into the old sources found

• Here is the solution:

Updated the rotors_gazebo_plugins package’s CMakelists.txt while or after building the RADI, the packages in the catkin_ws needs to be cloned as it is Following commands were used for solving the problem:

cp -a /catkin_ws/build/rotors_gazebo_plugins/Actuators.pb.cc /catkin_ws/src/CrazyS/rotors_gazebo_plugins/src/ && cp -a /catkin_ws/build/rotors_gazebo_plugins/Actuators.pb.h /catkin_ws/src/CrazyS/rotors_gazebo_plugins/src/ && cp -a /catkin_ws/build/rotors_gazebo_plugins/libmav_msgs.so /catkin_ws/devel/lib/

cd /catkin_ws && catkin build -j1

source /catkin_ws/devel/setup.bash

• The test exercise was changed from follow_road to follow_turtlebot as there were some model loading issues as down below:

[Wrn] [ModelDatabase.cc:340] Getting models from[http://models.gazebosim.org/]. This may take a few seconds.
[FATAL] [1656896254.063794315]: Could not wake up Gazebo.
[crazyflie2/hovering_example-5] process has died [pid 7437, exit code 255, cmd /catkin_ws/devel/lib/rotors_gazebo/hovering_example 

• Here’s the main update in the launch file for follow_turtlebot:

<!-- The following lines simulate the Crazyflie dynamics -->
    <include file="$(find rotors_gazebo)/launch/spawn_mav_crazyflie.launch">
      <arg name="mav_name" value="$(arg mav_name)" />
      <arg name="model" value="$(find rotors_description)/urdf/mav_generic_odometry_sensor.gazebo" />
      <arg name="enable_logging" value="$(arg enable_logging)" />
      <arg name="enable_ground_truth" value="$(arg enable_ground_truth)" />
      <arg name="enable_state_estimator" value="$(arg enable_state_estimator)" />
      <arg name="log_file" value="$(arg log_file)"/>
    </include>
   <!-- The Crazyflie position controller -->
   <node name="position_controller_node" pkg="rotors_control" type="position_controller_node" output="screen">
      <param name="enable_state_estimator" value="$(arg enable_state_estimator)" />
      <param name="csvFilesStoring" value="$(arg csvFilesStoring)"/>
      <param name="csvFilesStoringTime" value="$(arg csvFilesStoringTime)"/>
      <param name="user_account" value="$(arg user_account)"/>
      <rosparam unless="$(arg enable_state_estimator)" command="load" file="$(find rotors_gazebo)/resource/controller_$(arg mav_name).yaml" />
      <rosparam if="$(arg enable_state_estimator)" command="load" file="$(find rotors_gazebo)/resource/controller_$(arg mav_name)_with_stateEstimator.yaml" />
      <rosparam command="load" file="$(find rotors_gazebo)/resource/$(arg mav_name).yaml" />
   </node>
   <node name="hovering_example" pkg="rotors_gazebo" type="hovering_example" output="screen" />
   <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" />
   <node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher" />
   <node name="quaternion_to_rpy" pkg="rotors_gazebo" type="quaternion_to_rpy" output="screen" >
       <remap from="odometry" to="odometry_sensor1/odometry" />
   </node>

• For performance comparison within the docker container Docker Monitoring was done using cAdvisor Prometheus & Grafana. Here are the results:

follow_turtlebot with PX4(current)

follow_turtlebot with Rotors(prototype)

• Conclusion:

So, as seen in the video the amount of memory usage as well as the total cores consumed by the docker container varies. As the follow turtlebot exercise is still pretty light as compared to others so, the performance gap isn’t that great but in exercises like drone_cat_and_mouse the gap can change.

The total cores usage in PX4 (current) case stabilises at almost 5.25 to 5.75 as seen but in the case of rotors prototype the usage is at 3.75 to 4.0 while running simulation in browser as well opened console with code running.

And as for the total memory usage, in the case of PX4 (current) it’s at stable 1670 Megabytes (almost) and in the case of rotors prototype, it’s at 1520 Megabytes while running simulation in browser as well opened console with code running.