This past week was a great struggle to try to get the quad copter to talk back to the Arduino. As discussed last week, the Arduino library DZL was tested with the NRF24L01 but the quad copter could not bind with the Arduino, or rather with the communication protocol set up with the Arduino. So a few debugging techniques were applied to the library to find out exactly how it works and where the binding process fails. Adding to that, a new Quad copter with a built in camera with a resolution of 640×480, was purchased off E-bay and thanks to some swift delivery, it arrived in time to do some analysis on how the extra weight is managed on a comparatively small sized quad copter with similar powered rotors. A bit of time was also dedicated to take a quick look at the basics of Swarm Robotics and some algorithms that could be applied to the project.

A look at Swarm Robotics
Swarm Robotics is a fairly new field that emphasizes on controlling large-scale homogenous multi robot systems. These systems are used to develop useful high-level collective behaviour while composing of modules that are very simple in design. Therefore, a robotic swarm can range from a dozen to hundreds of modules. For our project, I’ll be aiming to make at least 5 modules to exhibit the proof of concept in application. The proposed swarm model for the system is also planned to be scalable so that extra modules can be added to the system without compromising functionality.

I believe that it’s about time to take a quick look at some of the algorithms currently being implemented in Swarm Robotics and discuss which of these algorithms might be highly useful in the case of this project.  The algorithms derived over the years are based around the concept that complex macro-level behaviours can emerge from simple interactions between agents. For this post, I will briefly describe two very popular swarm robotic algorithms as follows:

  • Uniform Dispersion: This is one of the first algorithms deployed on swarm robotics. This algorithm is very simple and elegant and can be viewed as a composite of two algorithms; one disperses the robots uniformly and the other explores the boundaries. In a nutshell, the dispersion part of the algorithm has the modules focus on locating their closest neighbours, calculates its distance from its neighbours and this is used to generate directional vectors away from the particular neighbours. Much like electrons, the closer the neighbours get, the more the module will get repelled away. The resulting behaviour is the robots moving away from one another. The other part of the algorithm is developed to attract modules to the fringe robots. Each robot figures out whether it is a Wall node (up against a wall), a frontier node(adjacent to open space) or an interior node (neither a wall nor a frontier). The wall and frontier nodes stay static during this behaviour and broadcast a message calling all interior modules towards them. The point of this part of the algorithm is to ensure that the interior modules keep moving towards the empty to be explored. After this phase, the algorithms are switched and the robots once again repel from one another causing frontier nodes to explore the free space about them. These two algorithms are therefore run in an alternating method. The modules don’t necessarily need to in constant connection with one another when using this algorithm.

 

  • Distributed Localization: The use of this algorithm involves the constraint of requiring constant communication and close proximity to one another so that no communication links are lost. One of the major problems of Swarm Robotics is for the individual robots to know where they are in the system. The implementation of this algorithm involves the use of beacons to denote location. The controller on each robot in this algorithm follows the following steps: i) Move in a general direction while maintaining X,Y co-ordinates based on                                                                                              local beacons                                                                                                                                                                                ii) Once the number of beacons goes below a certain threshold, the module                                                                                              becomes a beacon and begins broadcasting its position to others.                                                                                                   iii) If the number of dependant modules dips below a given threshold, stop                                                                                                being a beacon and loop back to step 1.

The result of this algorithm is that the swarm moves with the front modules becoming beacons and back modules continuing on (i.e.            leapfrogging to the front). This particular algorithm is very popular when generating maps of unknown terrains.

In terms of the application of the project, the uniform dispersion algorithms seems to be more applicable, however more Swarm Robotics algorithm will be examined and in perhaps a hybrid of a few algorithms will be used to develop the final swarm system to be used in the project.

New Quad copter toy with a Camera

As discussed a couple of weeks ago, a new quad copter with a built in camera was ordered with arrived late last week. Initial analysis proved that this copter is indeed much heavier while the propeller sizes are not much bigger. This copter however does not have an anti crash frame, and has a slightly larger capacity battery which is not much heavier than the previous toy. The added weight actually comes from a harder frame which protects the MCU from damage during crashes and the camera module. The camera stores any pictures or videos taken on a micro SD card which I presumes runs on a module that works of the SPI. The camera module also has a tiny microphone to capture sound during video recordings.

New Quadcopter Images and Selfie with Quadcopter

New Quadcopter Images and Selfie with Quadcopter

The added weight does cause some issues, the first being that the motor seems to be under more stress then the previous toy. This obviously leads to less flight time and faster battery discharge. Initial analysis show that the copter can fly effectively for around 5 mins. Another problem that is caused by the extra weight is much lower agility in movement and turns. One advantage that does come from the added weight is that there is less drift when hovering so the flight stability is slightly better. Unfortunately, this quad copter was also not able to bind with the Arduino and the NRF24L01 module.

Debugging the HCD library 

As discussed before, attempts were made last week to try and hack into the toy quad copters using an open-source on-line library. Unfortunately, the quad copter refused to bind with the Arduino running the library and a closer look into the source code for the library was taken. In general, the library works by following a set of commands that are sent to the quad copter to initiate the handshake. Once the quad copter accepts these commands it responds with a status bit and correspondingly, more configuration information are sent to complete the handshake and bind with quad copter so that it can be used with the Arduino. One important aspect to note is that the library contains the protocols for a specific type of quad copter that was used by the developer of the library. In fact, in the blog the developer goes on to say that the library is compatible with the NRF24L01 in a seperate post. So debugging was done on the library to try and find out in which part of the binding function the code stops working. Using the serial monitor, the code was checked and it was found that the main stumbling block was the first while loop where the Arduino waits to get the status from the Quad Copter is where the code is blocked.

Serial Monitor view of debugging

Serial Monitor view of debugging

There could be several reasons as to why this is happening. Most likely, the problem is the fact that the RF chip used in the quad copter is a cheap Chinese clone of more conventional RF communicators and may not work under the same protocols. The addresses and the registers used might also be the problem. To solve either of these problems, the existing chip must be hacked in detail and eavesdrop on the communication between the quad copter and the handset, which is a tedious task and will need some time as I have little experience in these matters. I will keep working on this for the time being, but also dedicate a bit of my time on trying to build a quad copter with the Arduino as my flight controller as a Plan B in case I am unable to solve the hacking problem. I currently have 16 similar motors with many spare propellers and a quad copter frame, so I might as well see how hard it is to build one on the side.


0 Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.