In this unit we will gain understanding and practice on how information is passed between different components of the drone such as the onboard computer (Aero Compute Board) and the flight controller (AeroFC).
You should have already been exposed to the basic concepts of the Robot Operating System (ROS) during the online portion of this class. These concepts including things like nodes, topics, messages, services, etc. If you are unsure/uncomfortable with what these concepts imply, there are great tutorials online for walking you through the basics of ROS. Please see:
Talker - Listener
We are going to put some of basic tools of ROS into practice on the Intel RTF Drone. We are going to start by creating and sending a simple message in one ROS node (i.e. talker) and receiving it in another. This portion relates to this ROS tutorial, but adapted to our needs.
First make sure you have the most recent codebase on the drone.
cd ~/bwsi-uav/catkin_ws/src/aero_control git pull upstream master cd ~/bwsi-uav/catkin_ws/src/aero_control/communication_pipeline
If you try to run
simple_talker.py and or
simple_listener.py you will receive an error stating
Exception: CODE INCOMPLETE! Delete this exception and replace with your own code
Step 1: Complete Talker
In your preferred text editor, open
simple_talker.py and replace/fill in the following code block with your own code:
'''TODO-START: FILL IN CODE HERE * create a string message that contains "Hello World" and the iteration number i ''' raise Exception("CODE INCOMPLETE! Delete this exception and replace with your own code") '''TODO-END '''
Once complete, you can run the talker node
After answering the following questions, you can kill the processes by hitting
Ctrl-c in each terminal
Questions Set 1:
List all rosnodes that exist after running talker.py
List all rostopics that are being present after running talker.py
What command do I run to see what is being published to the
What would I change in
simple_talker.pyto make it publish messages more frequently?
Step 2: Complete Listener
Now we will incorporate a second rosnode to subscribe to the topic created by
simple_talker.py and listen to the messages passed. Open
simple_listener.py and replace/fill in the appropriate code block.
Once complete, you can run the talker and listener nodes
After answering the following questions, you can kill these processes by hitting
Ctrl-C in each terminal. You will also want to commit the progress you have made so you can later push it to your team’s MIT GitHub repositories:
cd ~/bwsi-uav/catkin_ws/src/aero_control/communication_pipeline/src git add -u git commit -m "filling in code for talker and listener"
Questions Set 2:
List all rosnodes that exist after running simple_talker.py and simple_listener.py
List all rostopics that are being present after running simple_talker.py and simple_listener.py
In terminal I ran simple_listener.py I see information being printed. Does this mean simple_listner.py is publishing to a topic?
Step 3: Launch Talker and Listener
It’s a cumbersome to be opening a different terminal for every different rosnode you want to start. Instead of doing this, we can use launch files.
Before we make a launch file, we need to more properly set up our catkin workspace by turning
aero_control into a ROS Package and indicate it’s dependencies on
cd ~/bwsi-uav/catkin_ws/src catkin_create_pkg aero_control std_msgs rospy
Your Intel drone may already have
aero_control as a package. If you receive the error:
catkin_create_pkg: error: File exists: ~/bwsi-uav/catkin_ws/src/aero_control/package.xml, then you can skip ahead to Make Executables
This will create files
~/bwsi-uav/catkin_ws/src/aero_control/package.xml. You’ll want to track these new files on github, so add and commit them so you can later push them to your team’s MIT GitHub:
cd ~/bwsi-uav/catkin_ws/src/aero_control git add CMakeLists.txt package.xml git commit -m "starting aero_control as a package"
Next you need to make sure that
simple_listener.py are executable in order for the launch file to properly access them. This can be done as follows:
cd ~/bwsi-uav/catkin_ws/src/aero_control/communication_pipeline/src/ chmod +x simple_talker.py chmod +x simple_listener.py
Now you are almost ready to run the launch file that starts
simple_listener.py simultaneously. We’ve given you part of the launch file in
aero_control/communication_pipeline/launch/simnple_talk_listen.launch, but it’s incomplete. Can you figure out what is missing and add it yourself?
Once you’ve filled in the missing part of the launch file, follow these steps to run it
cd ~/bwsi-uav/catkin_ws/ catkin_make source devel/setup.bash roslaunch aero_control simple_talk_listen.launch
You should see the print statement from
simple_listener.py in your terminal.
A useful tool for visualizing how information is being passed by ROS is
rqt_graph (see references here and here for more information. With
simple_talk_listen.launch still running, open a new terminal and run:
rosrun rqt_graph rqt_graph
Question Set 3:
What needed to be added the launch file?
rqt_graphopen, use the button in upper right corner to save an image of the graph and include it in this report. Which components in the graph indicates rosnodes and which indicate rostopics?
Why do we need to run the command
source devel/setup.bashbefore running
Were there any steps that didn’t work or were particularly confusing? How did you work around them?
Step 4: Document and Push
Congratulations! You have implemented one of the basic building blocks of ROS! Now that you have this demo complete, you will want to push your code changes to your team’s MIT GitHub.
First double check that the repository you are working with on your drone or laptop points to the correct remote repository.
cd ~/bwsi-uav/catkin_ws/src/aero_control git remote -v
should return 4 lines of information, the two lines that start with
origin and end with
(push) should contain the URL of your team’s MIT GitHub repository for
aero_control. If not, let one of the instructors know so we can sort it out.
If that’s all set and you ran the commit commands in the previous steps, you should now be able to push those changes to to your team’s remote repositories with:
git push origin master
Finally, document the answers to question sets 1-3 and push those to your teams
documents repository. You can write up the answers any way you want, but the easiest is probably to create a file called
communication_pipeline_answers.md, and write a bullet point or paragraph for each question.
In the last section we passed basic messages between two nodes in ROS. This was done entirely in Ubuntu on the Aero Compute Board (or perhaps your laptop); it had no direct communication with the NuttX operating system that was running PX4 firmware on the Aero Flight Controller hardware. It we want our drones to fly autonomously, we need to be able to send commands to and receive sensor information from the flight controller.
Communication with the PX4 Firmware running on the AeroFC board is managed with a service called MAVLink. Similar to how ROS messages pass information between nodes on Ubuntu, MAVLink messages pass information between ROS/Ubuntu/Aero Compute Board and PX4/NuttX/AeroFC.
The MAVLink protocol is low-level, which makes it powerful, extensible, but also complicated to use. To simplify our lives we will make use of MAVROS. MAVROS can be thought of as a “wrapper” for MAVLink that simplifies the communication with ROS.
Step 1: Running MAVROS
Let’s start by getting MAVROS running. On the drone, use multiple terminals to run the following commands:
rosrun mavros mavros_node _fcu_url:=tcp://127.0.0.1:5760 _system_id:=2
After answering the following questions you can kill these processes with
Question Set 1:
What rosnodes are running?
In a separate terminal run
rosnode info mavros. Look through the list of
mavrosSubscriptions and Publications. Can you guess which topics could be used to send commands that control the drone? Which ones?
Some of the topics that
mavrossubscribes and publishes to have similar sounding names because they serve related, but distinct, purpose. For example, can you guess what is the functional difference between Publication:
Inspect the messages being sent on the topic
mavros/extended_state. Roughly how often do you get a new message? Do you think these messages originate from the Aero Compute Board or the AeroFC?
Step 2. Sending Commands
Next we are going to use the
mavros node to send commands to PX4 and receive information about the state of the quadrotor. Since we are only learning the communication structure of the drone, we won’t actually be flying it with these commands, just observing that they get passed correctly.
aero_control/communication_pipeline/src you should find two other files
command_generator.py. As with the previous section, these files are missing a block of code that you need to fill in; see the code for instructions on what needs to be completed.
Once you have completed writing your code, let’s test it out. On the drone in multiple terminals run:
rosrun mavros mavros_node _fcu_url:=tcp://127.0.0.1:5760 _system_id:=2
cd ~/bwsi-uav/catkin_ws/src/aero_control/communication_pipeline/src python dispatcher.py
cd ~/bwsi-uav/catkin_ws/src/aero_control/communication_pipeline/src python command_generator.py
Assuming you got no errors, answer the following questions (if you did get errors, are you able to debug them?)
Question Set 2:
What new nodes and topics were created by running dispatcher.py and command_generator.py that weren’t present when just running mavros?
Inspect the messages being sent on
/mavros/setpoint_velocity/cmd_vel_unstamped. Do they appear to be the same? Are the being passed at roughly the same rate? Which one is actually being sent to the PX4/AeroFC?
Why would we want to impose a limit on the velocity command sent to the flight controller?
As with the previous section, it is cumbersome to run each command in a separate terminal. To this end we have included a partial launch file in
aero_control/communication_pipeline/launch/mavros.launch. Can you complete the launch file and run it in order to kick off mavros, dispatcher, and command_generator simultaneously?
When all nodes are running, use rqt_graph to generate an image of the nodes and topics.
Step 3: Document and Push
As before, document the answers to the preceeding question sets and push them to your team’s
Advanced Topics: uORB
So far we have only seen communication on the Aero Compute Board and how to pass messages to the Aero Flight Controller. We haven’t actually looked at message passing that occurs onboard the Aero Flight Controller in the PX4 firmware. The Aero Flight Controller uses a different system known as “uORB”. We will cover this in a later lecture but you can learn more uORB in the link below: