Garbage Collector System

Garbage Collector System

I have been working with robotic system this semester at school. The idea is to create automated system, which will be able to transport something for us. It could be a garbage bean (originally) or it can use another modules, for bringing some coffee from the kitchen, or transfer a documents in a big office from room A into the room B.

The main goal for me was creating an architecture, which will make adding new robots, or modules for them easily, as well as adding another interfaces for asking the system what we want at the moment. (For example voice commands, or buttons, or clicking in computer application). Let's organize what will we talk about:

1) Architecture

2) User interface (Java socket connection to the server)

• Client side of the socket connection
• GUI

3) Server (Connecting users to the Droid Base) 

• Network server
• Bluetooth connector (to Arduino-based robot base)
• Logic Engine
• Robot road map (XML, Binary Tree)

4) Droid Base (Managing available robots and tasks for them)

• Bluetooth communicator (Through XBee shield)
• Wired communicator (Through Serial with another Arduino)
• Logic Engine

5) The Droid

• Wired communicator
• Motor control (Through Adafruit motor shield)
• Sensor analyzes (8 photo resistors)

So from this post you can learn about all of this, as well as about connection protocols between the project's parts. Use Ctrl+F search tool of your browser if you want to find a certain problem.


I. Architecture

  So you have learned already about all of this, but it's easier to see on diagram usually (;

Another diagram, you have heard already about this too. (Oh, and there is a mistake - must be "Network Interface" on place of "Ethernet Interface".)

Network interface implements an idealistic system-user communication interface, which, as I said, could be buttons on office tables as well.

For making more then one robot moving between more then two points, the idea of binary-tree map has been written. The root of the tree is our base, the leaves are end-points with their id's.

Here are communication protocols:

Grid Server - Droid base communication protocol
Data package view: [‘-’ | data | ‘-’], where data is char massive with length less than 34 characters and ‘-’ is a flag.
Any side after package sending do not waiting for confirmation. If a side hasn’t receive an answer from the other side, it will resend a package.
| data | package contains code characters at first and second place, which tells how to read data, and data characters from the third one. For some cases code characters is all data in a package.

This is a list of code characters. ‘-’ and ‘ ’ are already in use (the flag and empty symbol).

1. ‘sq’ - server query to base for status.
2. ‘ss’ - server request magistrale scan.
3. ‘sc’ - server calls for droid.
4. ‘da’ - ‘droid available’ status.
5. ‘du’ - ‘droid unavailable’ status.
6. ‘dm’ - magistrale map package. (possibly one of many)
7. ‘ds’ - droid has been sent.
8. ‘de’ - droid error. (could not find destination point).
9. ‘dv’ - droid successful.

Droid - Base communication protocol
Low level procedures worked out by EasyTransfer library.
Package is a structure with char command variable, and data int massive with length 4.
Any side will resend package while confirmation answer won’t be received.
command variable contains information about type of assignment from the one side, and completing assignment from another.
data contains information about magistrale map or route.

1. ‘s’ - scan map.
2. ‘g’ - go to address.
3. ‘w’ - wait for another command.
4. ‘a’ - droid is available.
5. ‘e’ - droid error, while completing last assignment.
6. ‘v’ - assignment has been completed.
7. ‘r’ - droid is ready to connect.

This is a quick diagram for Java's application part. Of course the difficulty of the Grid Server Engine with it's tree is incomparably larger then of the client side's application.

II. User Interface

Start.
After launching the application, you need to set your id-number, which your system’s administrator gave you.
Next you need to connect the server by clicking “Connect the Server” button.

Use.
If you need to call for droid - just click the ‘Call for Droid” button.
All information will be showed in the “Status” field, as well as necessary instructions. If you have incorrect id-number you need to check it with your’s administrator.
That’s it! Just that simple.

Here is the source code. The NetworkClient class is firing events and GUI catches them.

III. The Grid Server

Start.
First of all you need to create network connection by clicking “Create Network Connection” button. It will make able the users to connect the server.
Next you need to connect to droid’s base by clicking “Connect To Droid Base” button. It will make able the server to send queries and take responses from the base.
Then you need to load the map of bot’s roads by clicking “Load” button, or you can request the map scanning from droid’s base by clicking the “Scan Magistrales” button. The map is necessary for organising robot’s work. You can see the map by clicking the “Show” button. Leave’s id’s are users id’s, which supposed to be used at user’s application.
After this click the “Start” button. It will start system’s logic engine, which is needed for queries’ transactions.

Use.
You may check map accuracy by sending the droid manually to chosen user, by choosing proper id-number at “Send droid to” box.
By the log field you will be in touch with all information and queries of the system.
You can save current road’s map by clicking the “Save” button.
Also you can stop system work without breaking of the connections to the base or users by clicking the “Stop” button.

Yes, the system is that simple in use!

The server is much more complicated, but not too much. So first of all, the network server. It enabled connection to him, and listens to the ports, on which clients had connected. Another problem is, that we need to organize offline road's ids with channels. You can find how this problem have been solved, with some other problems here:

Another part is Bluetooth connector. The first difficulty is about different views on what server is, and what client is by BlueCove library, and by Bluetooth Bee module for the Arduino.
The second is truly arduino-sided problem, about bits loosing. Third one - arduino has 16-bit processor, and my computer is 64-bit - we have a problem of Intger size definitions and so on.
Protocol-use simplifies our situation, but nevertheless - think twice before you decide to use bluetooth in your Arduino project.

And finally - the Grid Engine. It fires events to the Administrator's console, and sends queries from network's part to bluetooth's and back, of course with thinking.
Also it uses writing into XML (simple XML database) and a binary tree.

IV. Droid Base

The droid base is at right on this photo

As I said bluetooth connection enabled by Bluetooth Bee module and Serial connection library. Wired connection (as on photo, just three wires), enabled by EasyTransfer library. The main goal of the base is too connect the robot and the Grid Server (because on larger scale droid can go out from bluetooth or wifi range, without a proper layer which will enable non-stop connection). There are variations of commands, which base can receive, and the task is to organize them in good way. Strategically the base will need to charge robots, and change modules for them if it's needed. But those are plans only (:


V. Garbage Collector Droid

First of all I need to say you, that I failed to find a proper algorithm, which will work wherever you want, with different lines under different lights and so on. I have written a program for moving by the black line on white paper, but because of hardware problems (Adafruit shield failure I think, when motors run, it's not shielding enough the arduino from the voltage change and it restarts.), so because of those problems I couldn't run any program, because the robot unpredictably restarts. It can follow the line, but it can easily loose it on lights change.

The first way I thought about, was to use 4 sensors. Robot starts on the line, and if left or right sensor data is lowing, that means that robot is going out from the line to the right or to the left accordingly. First time I implemented road vision "digitally" - if the sensor reading is low enough (I tryed both - constants, which works fine on paper, but on paper only, and not for too long; and also I tried dynamically change black-line definition, by remembering what was black line and what the current lowest sensor reading is). It hasn't worked well.
I used under-robot light, and program changes it's brightness on lg n time, where n is voltage for LED coded on numbers from 0 to 1023.

  I have used 8 photo resistors on the next construction. The idea was the same, and changing photo resistor's number hasn't worked out. But a new idea had come to my head - to use photo resistors as switches - if the sensor is closing to line, the reading is lowing, if it crossed the line - it's growing back. So we have a minimum, which can be used as switch for our sensor grid. I tried it on this base, and it should work on 2 wheel chassis, but 4 wheel-based are going to far from the rotation point while turning.

 I used it on my third version, which is most ugly and quick maded.
By creating 5 forward sectors, and knowing which sensor had detected the line last time the robot can correct it's speed. (Ex. if line is on the middle sector - max speed. If the line is on the left-to-middle sector - slightly turn right, if the line on the side's sector - stop and rotate in one place. In reality I'm using a different combination, but this is the main idea).
For crossroad detection side sensor are used, and if they do, it comes to logic, which way to go.
He's the code: