Next Tutorial: Command Line Tools
Overview
Some aspects of Gazebo Fuel Tools can be configured according to the needs of the library users. This configuration can be done via a YAML configuration file or programatically.
Gazebo Fuel Tools accepts a YAML file with the following syntax:
The servers
section specifies all Fuel servers to interact with. For each server, you must specify the URL to send the HTTP requests. If the server requires authentication, you can specify the token by filling the optional field private-token
.
The cache
section captures options related with the local storage of the assets. path
specifies the local directory where all assets will be downloaded. If not used, all assets are stored under $HOME/.gz/fuel
.
Guided Configuration
The gz fuel configure
CLI will walk you through the process of creating a ~/.gz/fuel/config.yaml
file. Just run the following command, and answer the prompts. Note that this command will replace your existing ~/.gz/fuel/config.yaml
if you choose to save on the last step.
Custom configuration file path
Gazebo Fuel's default configuration file is stored under $HOME/.gz/fuel/config.yaml
, but it is possible to load a configuration file from a custom path programmatically. Let's see how.
Create a file /tmp/my_config.yaml
with the following content:
Now, let's use a program that downloads a resource from a server in the custom configuration file. Let's start by creating a directory for storing all files:
Download the file download.cc
and save it under /tmp/conf_tutorial
:
Also, download CMakeLists.txt
for compiling the example:
Install the gflags dependency:
Let's compile the example:
And now the fun part, execute it:
Verify that you have the model in /tmp/gz/fuel/fuel.gazebosim.org/caguero/models/beer
, as you configured in your YAML file.
Walkthrough
Let's jump to the interesting parts of the program:
In the previous block, we can see how a ClientConfig
is instantiated. This class lets you specify different options to be customized by the client using the library.
Next, we check if -s
(server) has been used when invoking our program. If that's the case, we instantiate an object of ServerConfig
and we fill the URL with the value of the -s
flag.
Next, we use AddServer()
to register the new server. The previous block shows an example of a programmatic way of configuring a Fuel server. Let's focus on the next interesting piece of code:
Here, we check if the user specified a -c
(config) option. If so, we need to tell conf
about the path where the configuration file is located. For this purpose we use SetConfigPath()
. As we're interested in using a configuration file, we need to call LoadConfig()
. It's important to note that if we call LoadConfig()
without calling SetConfigPath()
beforehand, a default configuration file will be loaded (and created if it doesn't already exist under $HOME/.gz/fuel/config.yaml
). If the user doesn't call LoadConfig()
, no configuration file will be used at all.
Once we have all our configuration ready and captured in the conf
object, we can instantiate the FuelClient
object (client). This is the class that performs the main operations, such as the model download described in this example.
The code above sets the owner and name of the requested resource. Finally, it iterates over all available Fuel servers and tries to download it.