Home‎ > ‎

Quadcopters | 360 Degree Proximity Sensing Project Overview



Project Overview

We've recently started another Proof-of-Concept (PoC) to determine how best our  IRCF360 sensor could be used as a 360 proximity sensor on a micro UAV / Drone / quadcopter for autonomous flight (such as through a 3D mazes ) or even pilot assisted flight modes; for example when flying in confined areas where the ceiling, walls and ground needs to be continuously monitored to avoid collisions.

3D maze for autonomous drone racing


Some robot controllers (e.g. Naze32) have the option of being able to connect an ultrasonic sensor, to assist with low-level flying  at high speeds. We believe this concept could be extended even further to achieved a 360 degree proximity sensing  in the X, and z axis to form a proximity sensing  bubble;  using a couple of modified IRCF360 sensors.


360 degree proximity sensing bubble sphere


There are few ways we thought we could do this:

1. Parse the S.BUS signal that's sent from the FrySky receiver to a flight controller with modified control data from the IRCF360. So when an obstacle is detected within a 360 degree sphere (such as a wall, ceiling, ground) the IRCF360 modifies the S.BUS signal in the opposite direction.

2.Develop 2x serial interfaces on the Arduino; where one is connected to the IRCF360 and the other is connected to the flight controller. This means that when proximity data is received from the IRCF360 sensor, it is parsed by the Arduino and sent to the flight controller  (such as the Naze32) as modified and corrected data.

Serial Interface between IRCF, Arduino and Flight Controller

3. Send Telemetry data back to the transmitter as audible warnings to the pilot. This is of course then up to the pilot to take action on the information received. 

Here is a short video explaining the  proof-of-concept in more detail. 


Overview of the Proof-of-concept

FrySky / CCD3 interfaces to 360 degree IR Proximity SensorFor this PoC, we decided to start investigating the S.BUS option first. This was mainly because also due to being generally interested to understand the details of the S.BUS,  so we could build other devices that could be controlled by directly from the radio such as a PICmicro and Arduino buzzers, leds, Cameras and Gimbals.


Step 1: Building Real Time Graphical Representation of the 16 channel S-BUS protocol

For this project we thought we'd use a small Arduino; such as a Micro, Nano or similar. To help us understand the S.BUS protocol, we wanted to created a real-time graphical representation of the 16 channel S-BUS protocol, so we could really visualize what's going on in the background.


We used the processsing.org java sketch which is an open source programming language based on Java to help the electronic arts and visual design communities and is also based on wiring as the Arduino IDE.

Once we could confirm that everything was behaving and working correctly, we could start working on the Arduino Sketch. The processing.org JavaScript language is similar to the Arduino, so it was relatively easy to port the Processing sketch to an Arduino sketch.

See this webpage for further details of the processing sketch and how we did this. See also also this YouTube video.

Real-Time Graphical Representation of the 16 channel S-BUS protocol

Step 2: Interfacing the FrSky S.BUS protocol  to an Arduino microcontroller.

The porting of the processing.org sketch was relatively straight forward. There were some challenges due to the differences on how the serial port works in Arduino compared to processing.org. 

  • We first tested using a Freeduino (an Arduino Uno clone).  Here is a video of the first test
  • The second version was with an Arduino Mino Pro



Step 3: Real time Graphical Represenation of the FrSky S.PORT protocol

See the following webpage for further details of this processing.org java sketch


Real time graphical representation of the Fr.Sky S.PORT Protocol





The results of the project are being documented  in this sections.as we go along  See the breadcrumbs navigation at the top and bottom of these pages to navigate to other pages and topics:

Scope

As our current version of the 360° degree sensors have been designed for close-proximity,  indoor robotics i.e. robot swarms; where the environment can be controlled and where the proximity range has been specially tailored for short range sensing and inter-robot communication - The starting point of the PoC will therefore be for experimental &  in-door use. 

The Journey

Who knows what we'll discover on this journey. We welcome contributors  to support development in this project and also to start new branches if they like. 


The main focus (at this time) will be to develop an interface between our IRCF360° proximity sensor to quadcopter flight controllers; either indirectly using an Arduino or other micro-controller or direct connection  using the existing S.BUS, I2C or other interfaces found on the flight controllers. One of the channels will be programmed to turn on/off the sensor, in a similar way as existing sonar sensors are used. 


As infrared sensors don't work well with dark backgrounds, we anticipate that a combined 360° sonar / IR sensor may come out of the research we are currently doing. 

Proximity avoidance challenges:

Some of the following challenges will be used to test the degree of success of use in autonomous flight:

  • Level flight : Steady flight  - Being able to hover above ground.  The following challenges will be used to test the degree of success:  Ground avoiding obstacles by increase in height at the same time avoiding obstacles in the area of N, NE, E, SE, W, S, SW, W, NW   and above. 
  • Level flight : Steady flight - as above but with floor obstacles  -
  • Level flight : Maze Test-1 - Being able to autonomously navigate through  a maze with fastest speed and fixed height
  • Level flight : Maze Test-2 - as above - but with floor obstacles : 
  • Funnel Maze Test: The goal is to fly autonomously as fast as it can through a funnel maze and stop if the restrictions are too narrow and try another route.

Timeline:

This is of course dependent upon the number of interested volunteers and  time available; but we hope to have some results by end-Q4 2016 with the current team. 
We see there are are various approaches to take which need to be reviewed. e..g some include:

  • Reviewing the interfaces  on the OpenTX RX's and TX's such as to FrySky
  • Reviewing open source flight controllers and identify best methods for  achieving modified flight control
  • Creating a new branch of our ICRF360 senor module with dedicated firmware for interface to flight controllers
To get started we are reviewing the RS232, RSSI S.BUS protocol. Details of this are described in the following sections
For the 2nd approach we are reviewing various Ground Control System (GCS) that could be reused or modified for our project. This seems more challenging in the long run. The main criteria is that they are open source and supported by an active user group - such as the ->  following


Blog & Discussions:

Blog: Please add your comments to the blog:

Discussions: