Swarm Simulations, Quadcopter Design

This week the focus was given on trying to develop a simple simulation to test out one of the algorithms discussed the previous week. The algorithm used to try out the simulation was the Uniform Dispersion algorithm. Some work was also done in the aspect of a proposed design for the quad copter considering that newly assembled ones could be used in the event the hacking of the toys isn’t as successful. The development of a demo for multi-agent communication will also be briefly discussed.

Simple Swarm Simulation

Although the algorithms that could be used were discussed, it is still important to figure out whether they would work practically. For this, a Matlab m-file was developed to try and simulate the uniform dispersion algorithm via simple plotting operations. The function was written to follow a similar methodology as the description of the uniform dispersion algorithm with the exception of the frontier node broadcasting the its location to the bots. Instead, in the function the nodes move forward by default. The simulation is basically a collection of 30 plots made by the function, with each plot updating the positions of the modules in the system.

The criteria for this simulation was set to constrict the system to 5 modules, all starting from the same position, and moving cohesively and consequently dispersing uniformly. The plot is governed by a boundary of 20×15. These parameters set were completely arbitrary and can of course be modified later as per required. The following is are images of the simulation on 5 separate iterations that give a simple idea of how the swarm behaves under the algorithm and the implementation planned:

The simulation helps show that the algorithm is somewhat effective if directly implemented. There are some kinks to be worked out, however an added feature seen is that if the algorithm is used just as it is, a sort of formation flying can be achieved where the bots can fly in one horizontal line, which is a decent application for the overall objective of searching a wide area. Of course, this is just a simple simulation and in the coming weeks and months, more complicated simulations must be run to understand and predict the overall swarms behavior further.

Design of Quad copter 

As discussed previously, some effort was during the week was given to the design of a quad copter that could be assembled and used for the project in the event that the hacking of the toys proves ineffective or too difficult. Designing and creating a new quad copter from scratch has its advantages mostly lying in the fact that I can control the elements on the quad copter more effectively, and more components and sensors can be added to the quad copter and the whole system integration would be much simpler. An Arduino to Arduino communication would also be much simpler to implement. Keeping all these facts in mind, it was thought that the best solution would be to obtain a frame and try to mount the motors and rotors already available from the equipment at hand to develop a design. As such, a specific frame was obtained from eBay. However, the flaw of online shopping flared up, as the frame ordered turned out to be entirely too big and bulky for this project.

After some survey, it was found that the best design would perhaps be the one employed in the broken quad copter obtained earlier. The model of that particular brand of quad copter is the WLToys V212. As discussed before, the larger propellers provide additional thrust for the same amount of motor power as the smaller ones and in fact could be more stable than the smaller copters due to slightly larger size (higher inertia due to wider arm-span). One more very good thing about this particular toy design is that the spare parts are very widely available so it is very possible to create a whole new copter using the Arduino as a controller without having to buy the whole toy itself. The following is a few AutoCAD drawings drawn to analyse the design of the quad copter for future reference:

Using the available broken copter, the motor wiring was modified to be able to plug into the Arduino and the frame was assembled to see if the Arduino could fit on top without affecting the rudder. Preliminary visual inspections were encouraging and corresponding tests of running the motor with the Arduino on board was also good. The weight shouldn’t be a problem as even with one rotor, plugging the battery to the rotor showed that the copter was slowly lifting off. However, a simple motor driver module will be designed to work with the Arduino so that more power can be provided to the motor without damaging the Arduino. The following images show the assembly (-1 quad copter arm that was damaged and needs to be replaced [spare parts on the way]):

In the coming weeks, the quad copter assembly would hopefully be tested out complete with the Arduino running. Sensors, such as gyroscopes and accelero-meters, will be added as per requirements to the system. As for the design currently, the most significant addition to the frame would be a more secure plate for the Arduino to sit on (currently held to the frame with cable ties) and any added circuitry will be mounted underneath the plate to protect against any collision with the propellers.

Multi agent communication demo plans

Considering that the single agent communication was successfully achieved, it is hoped that the prospective multi agent communication between the swarm modules could be simulated. Regardless of the swarm algorithm used, the modules in the system must have some means to share information with each other. So using the existing knowledge about the NRF24L01 modules and its working with the Arduino, a simple program is planned to be developed to demonstrate a user-less Arduino-Arduino communication between the flying modules themselves. The following is a flow chart of how the proposed system in this demo should work:

In general, the serial monitor will be used by the user once to denote the initial positions of both copter in the demo (preferably close to each other to demonstrate some form of swarm behavior). The input is necessary as it is not fixed yet as to which process the swarm will use to determine their location in the system. Once both modules receive the positions correctly, the two modules of the demo must communicate with each other and find out which direct they should move in. More progress on this is expected in the coming week.