Quadcopters | 360 Degree Proximity Sensing 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.
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.
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.
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.
For 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.
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
See more details of how to connect the FrSky X4R receiver to an Arduino on the following webpage.
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
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:
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.
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.
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: