Quadrotor Altitude Control and Obstacle AvoidanceDescription: The Kinect is mounted on a quadrotor and used for closed-loop altitude control and basic obstacle avoidance.
Submitted By: UC Berkeley Hybrid Systems Lab (Patrick Bouffard, Jeremy Gillula, Haomiao Huang, Michael Vitus, Claire Tomlin)
This work is part of the STARMAC Project in the Hybrid Systems Lab at UC Berkeley (EECS department). http://hybrid.eecs.berkeley.edu/
The attached Microsoft Kinect delivers a point cloud to the onboard computer via the ROS kinect driver, which uses the OpenKinect/Freenect project's driver for hardware access. A sample consensus algorithm (from pcl) fits a planar model to the points on the floor, and the vehicle's altitude estimate is derived directly from this model. All processing is done on the on-board 1.6 GHz Intel Atom based computer, running Linux (Ubuntu 10.04).
Two use cases are demonstrated in the video.
In the first, the 3D sensor data is used only for altitude determination. Since the vehicle shown is not otherwise equipped with an effective indoor altitude sensor onboard, this enables flight outside of the lab.
The second use case takes place within the lab. The 3D data is again used to provide altitude, but to allow autonomous operation, a Vicon MX motion capture system is used to provide the other necessary degrees of freedom (x, y, and yaw). The 3D point cloud data is also used to determine the presence or absence of an obstacle within 1 m in front of the vehicle--whenever this is the case the vehicle pauses until the path becomes clear.
We consider these demonstrations to be straightforward proofs of concept showing that the Kinect sensor is a viable and useful addition to a small quadrotor platform with modest onboard computing. Besides the code directly related to this proof of concept, we have also released a framework for performing research experimentation on robotic quadrotors, in the form of the starmac-ros-pkg repository. This BSD licensed codebase is modular and can be easily adapted to additional quadrotor vehicles.
(See also this earlier video)
How to Reproduce Your Entry
Code to Checkout
ROS Repository starmac-ros-pkg provides all the functionality required for this demo, including a general purpose framework for operation of a quadrotor UAV such as the Pelican. The starmac_kinect_obstacle_avoidance package contains the parts specific to this demo--more reusable/generic components are found in other packages. See starmac_flyer/Tutorials/Installation for installation instructions.
There are many, which should be resolved by installing the above stacks. But the key ones for the demo are below. The demo was developed using unstable -- it may be possible to get it to work with cturtle but in particular, a recent pcl is needed.
The main feature from the fork that is needed is the capability to provide a (potentially time-varying) list of indices into the full 640x480 point cloud for the driver to actually publish. This capability could be implemented in a nearly identical manner in openni_camera. The forked code also provides the ability to disable the RGB stream to lower the USB bandwidth and the published point cloud includes only XYZ values with no color information. The combination of less computation and less data allows the altitude loop to operate at the full 30 Hz available from the sensor despite the modest on-board CPU.
Ascending Technologies Pelican Quadrotor
With Atom Processor Board option
- Microsoft Kinect
- Mounted (obviously) on top of the Pelican, tilted down about 25 degrees from horizontal and facing 45 degrees CCW from the "forward" (marked with orange tape) rotor arm.
The Kinect can be powered directly from the main battery; the vehicle shown in the demo is using an 8000 mAh battery from ThunderPower. See kinect/Tutorials/Adding a Kinect to an iRobot Create for one example of how to power the Kinect from a battery--however in our implementation we didn't bother with a regulator as testing showed the Kinect was able to operate well below the voltages at which we would recharge the battery anyway.
- There are obviously some details of the power and mechanical attachment that are not described here but our choices were largely driven simply by the materials we already had on-hand in the lab and there's nothing terribly special about the way we chose to do it. But for anyone interested in details (like exactly what nylon standoffs were used, etc) then we can certainly provide them on request.
Vicon MX motion capture system (for autonomous flight demo -- not required for manual flight demo)
Joystick (Logitech Extreme3D Pro is used in the demo but any joystick compatible with joy could work)
Note: The code is modular--this demo could run on any similar platform by replacing the asctec_adapter and asctec_autopilot nodes with functional equivalents for another quadrotor, or replacing the Kinect with some other source of sensor_msgs/PointCloud2 messages, or replacing the Vicon system with another source of nav_msgs/Odometry messages.
In each case, roscore should be running onboard the quadrotor, and it is recommended that a rxconsole is run on the ground station computer. Then use one of the following launch files depending on the scenario:
Manual Flight with Kinect-Derived Altitude
roslaunch flyer_kinect bringup_flyer_kinectalt.launch
Autonomous Flight with Obstacle Avoidance
roslaunch starmac_kinect_obstacle_avoidance patrol_demo.launch