Last update I discussed difficulties using my functions in conjunction with RotorS/Gazebo. This week I was focused on finding a method to that would not create a ‘segmentation fault’ while running the ROS nodes I created. I have discovered a few important details regarding why I was experiencing a ‘segmentation fault’ and how the RotorS package interacts with Gazebo.
A document from the group that created RotorS explained that motor commands to drones can be executed by publishing to a specific ROS topic. Trying to simply edit the functions that were provided in the RotorS nodes using calculations from our logic as the input did not yield any output because of differences in the type of variables used (i.e. our logic outputs an int while their logic needs a char). For the past month, I have created functions and executable nodes that would publish to the appropriate topic and publish to our mocap and telemetry messages for our state estimator. Any time I attempted to call the ROS publishers functions I created from inside of the main function of the executable nodes, I would receive a “segmentation fault” error. However, I noticed that even without running executable nodes, there were ROS topics still being shown when using ‘rostopic list’ in the terminal. I learned that Gazebo is primarily controlled by creating plugins and I was getting an error because I was trying to access a ROS topic that was already being used by them. This means that I need to change my focus from the executable nodes to the plugins to publish the values from our logic.
My objective is to create my own plugin for our logic, which will work with the other plugins used by RotorS (i.e. wind disturbance and sensors). I will attempt to publish telemetry messages first. The message name should show up in the terminal when I use ‘rostopic list’ after launching gazebo, since plugins go beyond RotorS logic and use header files directly from Gazebo. Fortunately, my functions can still be utilized with a few tweaks.