Skip to content

Latest commit

 

History

History
172 lines (113 loc) · 7.26 KB

README.md

File metadata and controls

172 lines (113 loc) · 7.26 KB
Raw

Flight Arena Gazebo in Starling

This repository contains a simple gazebo model of the flight arena within a docker-container for use with the Starling eco-system. This example currently ships with a PX4 based SITL by default.

flightarena

Shape

Flight arena is 15.6m x 11.8m x 5m (x, y, z) tall.

_________________________________
|                                |
|                                |
|                                |
|_                              L|
|C|
|  |                             |
|__|____________                 |
|___|_V_|___|___|                |
|                     _____ _____|
|_    _____    ______|__E__|_____|

The coordinate space is x positive is up and y postivie is left (w.r.t the ascii figure).

The flight arena origin is offset by (0.5, 0.7, 0.0) from the center of the space. This coincides with the vicon center

Features

Static Gimbal Model

This container also contains a yaw-pitch controllable static gimbal. You can enable the gimbal by passing in an environment variable SPAWN_GIMBAL=true. This is done automatically using the make run_gimbal command. The gimbal contains a number of spawning environment variables which can be modified.

The gimbal can be controlled through a set of ros topics. The /<gimbal name>/set_gimbal_orientation topic accepts a geometry_msgs/msg/Quaternion as an orientation relative to its starting position.

The current orientation of the camera can be accessed using the /<gimbal name>/get_gimbal_orientation geometry_msgs/msg/Quaternion topic.

Vision Position Tracking

The motion_tracker_sim ros node has been developed to mimic the VICON motion tracking system we have at the arena. It reads the gazebo local entity positions through the model_states topic.

It first filters entity names by the MOTION_TRACKER_ENTITY_PREFIX_LIST environment variable which is a space seperated list of entity prefix names. By default this is set to "iris gimbal rover". It is assumed that wanted entity names have a name of format <prefix>_<id> where the id is unique across all vehicles.

It then queries for the current list of topics to find the current list of active vehicles. It looks for namespaces which have a mavros subnamespace. Namespaces are assumed to be of form <ANYTHING>_<id>. Again the id is assumed unique. An entity id matches a vehicle id if the id's are the same. The entity's pose is then forwarded over /<vehicle_id>/mavros/vision_pose/pose by default.

Note that the simulator SITL sensor fuser needs to be able to process inputs from external vision on this topic. For PX4 this involves setting EKF2_HGT_MODE to 3 and EKF2_AID_MASK to 24 (EV_POS+EV_YAW). As of writing this can be achieved by setting the ENABLE_EXTERNAL_VISION env var for the px4-sitl container.

Usage

Local Docker

Build and run the associated world and element into a container by running the following

make run
# or if you want the gimbal to also spawn
make run_gimbal

# just running `make` will build but not run it

The Gazebo web interface is then available on localhost:8080.

On Linux, any MAVLink compatible GCS can be connected to UDP 14550. Many GCS will do this automatically.

On Windows, any MAVLink compatible GCS can be connected to TCP 5761.

If you wish to run with additional drone simulation stack (SITL, MAVROS) and GUIs, then you can use the associated docker-compose file

Note: This uses the PX4 SITL by default.

make
docker-compose up

Note: The gimbal is spawned by default

The docker-compose file also includes the UI which you can run to double check the image output of the gimbal. Accessible via localhost:3000

To check the ROS network, you can either docker exec -it <containerhash> bash into the container, or you can run make run_bash which will put you in a shell on the same network. Then to access the ros2 topics:

source /opt/ros/foxy/setup.bash
ros2 topic list

Running with Murmuration

This container can be easily run with the Murmuration starling cli.

First build and run the associated world and element into a container by locally running

make

Then start the starling instance as usual, e.g.

starling start kind # one drone
# or
starling start kind -n 2 # two drones

Then startup and load all of the simulation files. You can specify the simulator and sitl launch files, and load them in locally.

starling simulator start --simulator_kube_deployment_yaml k8.gazebo-brl.yaml --sitl_kube_deployment_yaml k8.px4-sitl.yaml --load

This command uses options to point to the local variants of the simulator and sitl launch files. These launch files contain the following differences:

  1. The simulator uses the container with the BRL Environment. This includes the motion tracker node.
  2. The SITL contains an option which enables vision position tracking using the motion tracker node, and disables GPS. This emulates the VICON setup at the BRL.

During development, you do not need to restart the entire cluster. If the simulator errors or breaks, you can just restart the simulator.

starling simulator restart --simulator_kube_deployment_yaml k8.gazebo-brl.yaml --sitl_kube_deployment_yaml k8.px4-sitl.yaml --load

Troubleshooting

The simulator needs to download some model files when it is first run so it will likely fail to spawn the vehicle. Leave it running for a few minutes then use Ctrl+C to exit and run it again. This should allow the model to spawn. The first time the model attempts to spawn, the simulator will need to download files for it too so it may be slow to start. Subsequent runs should be much faster.

When running the docker-compose, it will create a docker network called BRLFightlArenaGazebo_default which any additional calls to docker run can use.

Files

Flight Arena world file and models

The BRL world file is in the flightarena folder. The elements within the flight arena are all hard coded boxes.

Note: need to find a way to apply texture

3D Gimbal on tripod

The gimbal is split into 3 parts.

  1. The gimbal model which is located in systems/models/gimbal_small_2d
  2. The gimbal plugin i.e. the gimbal controller in systems/gimbal_plugin
  3. The gimbal tripod with camera which is located in systems/models/gimbal_tripod

Any changes made to any folder can be rebuilt when run make

Developing your own ROS2 controller

An example offboard ROS2 controller can then be conncted to SITL by running the following in a separate terminal:

# Download the latest container
docker pull uobflightlabstarling/example_controller_python

docker run -it --rm --network fenswoodscenario_default uobflightlabstarling/example_controller_python

See the docs for further details

Configuration

Gimbal Configuration

There are a number of environment variabels used which can be used to control the initialisation of the gimbal:

  • GIMBAL_NAMESPACE the name of the gimbal
  • GIMBAL_HEIGHT the height of the spawned gimbal
  • CAMERA_NAME
  • CAMERA_HEIGHT pixel height of camera
  • CAMERA_WIDTH pixel width of camera
  • CAMERA_ROTATION fixed rotation of the camera
  • GIMBAL_INITIAL_PITCH
  • GIMBAL_INITIAL_YAW