Home » Ground robots, Ideas, Programming, Refining the project, Testing » Merging our work together: the beginnings of worthy and notable results.

Merging our work together: the beginnings of worthy and notable results.

It’s been two weeks now we have been working together in order to merge our work (one on the drone/image analysis and the other on the land units/flock behavior). This post will present you our latest changes, improvements and show you the first results we came out with.

 

More about the flock behavior

The flock behavior is not entirely implemented yet. By “entirely” and “yet”, we mean that we only have two robots: one leading and the other one following, being as such the only following member of the flock. Still, the flock behavior is on its way to the full implementation and we have right now a lot of features that make the system properly working. Among those features, you can namely find:

 

An enhanced GUI

We wanted to be able to choose the bricks we wanted to use, be able to reconnect them if any problem happened, without being forced to restart all the program and the bricks. We came out with the following design, handy for taking control according to our needs and to display the information we needed from the bricks.

 

First notable thing is that the GUI is dynamic: it will display a number of lines according to the devices initially added in the program. For each device, you can connect it in order to add it to the flock simply by clicking on its button or clicking on the “Connect all bricks” button.

 

 

Once connected, the second button will allow to take control of the brick either using the controller, or writing in the field with command lines compatible with the brick’s interpreter. The brick will feed the computer back in real-time: confirmation message on the first label and the battery level on the second one (we will talk more about this one later).

 

The change of leader

The change of leader is something we wanted to focus on because no one never knows what problem is going to happen during an experiment and for instance, the leader might perish. So, at this point, it was important to know what strategy to adopt if the flock loses its leader. The solution we used is simply to change randomly the leader if this one is lost. Nevertheless, another solution can be added: we could indeed find the nearest robot to the leader and give it the lead. Another solution would be to give different priorities to the robots as if they had more importance according to their status (it is easy to state that a tank is more likely to take the lead rather than an ambulance carrying people).

As we mentioned before, it is possible to change the leader of the flock and thus change the formation in real-time. The bricks in use are checked quite often (in a separate thread); so even if a brick connects to the flock after the program has started or disconnects from it during the experiment, a new leader will be picked, automatically or manually. Mentioning that, the notion of disconnection brought us to develop an interesting feature that follows.

 

The management of dead units

If we want to compute the positions of every brick, we need to know the exact number of units in the flock and if they are properly connected. If not, we would have a lot of delay and this would tremendously affect our results. The brick must warn the computer of its state so as to ease the computer in its calculation.

As soon as a brick is connected, it has a thread running, giving every half second a heartbeat. On the computer side, we make sure for each brick that we receive those heartbeats. If not, after five heartbeats missed (2.5 seconds of silence from the brick), we shut the connection and get ready to re-open it whenever the user wants it (maybe the time to fix the brick and put it back on track). At the same time, the brick itself sends its own battery level in every heartbeat: this is an information that can be relevantly used by the user and depending on a certain threshold (that we set around 6,1V), the brick sends a message “Battery level too low”, shuts the connection with the computer and turn itself down.

Here is a sample of the computer-side code for the heartbeat counter checker.

public void run()
	{
		resetCount();

		while (getHeartBeatChecker() < 5) {
			try {
				Thread.sleep(500);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}

			setHeartBeatChecker(getHeartBeatChecker()+1);
		}

		brick.closeConnection();
		interrupt();
	}

 

An oriented flock

This is the feature we are the most proud of and where the omniwheels are the most useful and worthy. The flock is not just supposed to follow the leader in a simple direction: no matter which direction the leader is going to, the flock is going to stay behind. Thus, the flock is moving really often, especially when the leader is changing direction, but this is even more pleasant to watch when it happens (this will be completely covered in the next and final article about the flock behavior, this is just a sample/teaser).

As soon as the leader changes direction… …the flock adapts and changes its orientation

 

An enclosure system

The field of view of the camera can be a major problem in our project. For instance, a robot can be asked to go out of sight so as to respect the position it is supposed to be at. This is not a suitable behavior (indeed, we want to keep all the units in the flock) so every time a robot is close to the limit of the FOV, it is asked to get closer to the leader. The drone is supposed to be on top of the leader, so the units will get closer to the camera’s FOV doing such.

 

What the flock looks like so far

Very first working test

On this video, the flock is just supposed to stay below the leader (blue unit) and thus does not take care of the orientation given by the user/leader: the flock is supposed to stay oriented towards the white wall at the background.

The behavior is not suitable at all, the robot stops and starts over all the time: we’re not getting the fluidity we were looking for. This is why we implemented a P (proportional) correction on the movement and it fixed the problem as you will see it in the next videos. Nevertheless, a first step was made: the flock was moving as expected and it was ready to go to the step further.

 

Testing the oriented flock

From now on, the flock is oriented, no matter what direction the user sets (the red unit follows the blue one, once more). Nonetheless, we didn’t implement a collision avoidance layer yet, so you might want to be careful not to change the orientation and driving forward another robot for instance.

 

The robot behaves as expected. It even seems to reproduce the movements of the leader with a little delay but the flock is only positioning itself at the opposite direction of the leader. The P (proportional) correction is working quite well: we don’t have any overshot and it seems to be sufficient for what the robot are supposed to do.

Taking a closer look to the “edge limit” feature

The only thing you have to know here is that the black stripes on the floor are the limits of the field of view. From this point, the behavior is pretty simple: every time the a robot is soon to be out of the FOV, it is asked to get closer to the leader.

The system is properly working. When the leader is no longer seen on the image (that shouldn’t happen because the drone is supposed to stay over the leader, but this is just for testing purposes), the robot following gets closer to the last recorded position of the leader (which was along the limits of the FOV)  and therefore doesn’t go out the FOV.

At this point, it is interesting to observe the whole behavior and get surprised with things we didn’t expect. For instance, when the leader is out of sight, the robot following gets slower and sometimes move to unpredictable positions (still along the FOV, and it might be due to some misinterpretation of the color recognition) and seems to be lost without its leader. As soon as the leader comes back in the field; the proportional correction implemented on the movements make the robot almost run towards the leader. Call that loyalty or something else, but it’s always nice to see that basic behaviors merged together can unexpectedly lead to real ones…

Comments are closed.