Data transmitted through the microhopper is our primary source of control. Lost packets may cause delays in the control application, but corrupt packets could apply faulty control entirely. We have therefore developed a simple data packet structure to ensure the receipt of only valid, uncorrupted packets. This packet is similar to a standard UDP packet, with some additional properties and error checking code.

Header fields

· Source The computer is identified as ‘0’. Each robot is identified by a unique code, starting from 1 and increasing relative to the number of robots, generated from the dip-switches.

· Destination Destination codes are the same as source codes.

· Flags This field is available for any special control characters that do not require a full 4-byte representation. Our current code used this field for tasks such as control algorithm identification, and gripper state.

· Length Number of valid data variables in the data field (max of 10).

· Checksum checksum on the header only

Data fields

· Data The data consists of space for 10, 4-byte variables. In C, this is easily accomplished via a union between a float, integer, and 4-byte character string. In VB, we must define a “CopyMemory” function to translate a 4-byte string into either a Single (4-byte float) or a Long (4-byte integer), and vice versa.

· Checksum Checksum on the data only

Examing the above figure, you may notice the “padding” bytes. In order to align data variables with the 32 bit boundary (floats and integers MUST be on 32 bit boundaries), the C compiler adds these alignment bytes to the packet. This must be taken into account when programming packet commands in Visual Basic, as VB does not automatically add these alignment bytes. These bytes make the total packet structure 52 bytes long.

Note we take advantage of the padding to automatically insert our synchronization start/stop flags (253/255) without any increase in packet size.

Communication Architecture

We considered a number of communication architectures during the course of our project development. The initial objective was to develop a standard that was scalable to any number of robots, but this was far too problematic. Instead, we focused on a two-robot (plus computer = three microhoppers) communication scheme. Here, we will discuss three alternatives we considered: a token ring, a transmission/retransmission scheme, and what we term “alternating communication.”

Token Ring

A token ring protocol circulates a “token” among the robots in a round robin manner. A robot can only transmit when it gets the token. If the robot has a token, but no data to transmit, it passes the token to the next robot in the ring.

Advantages:

· ensures that packets do not collide

· provides all robots a chance to communicate quickly

Disadvantages:

· eats up communication bandwidth with non-data packets (tokens)

· few data packet transmission = bad performance for real-time control

· lost token = communication ceases. We therefore require either a retransmission algorithm, or a supervision (computer) to reinitialize the token.

Conclusion:

Although a token ring would be interesting to attempt, we decided it was too broad and general a protocol than was necessary. We only communicate between two robots, and can avoid the pitfalls of the token ring with some kind of alternating communication. This leads us to our first transmission attempt, detailed in the next section.

Transmission/Retransmission

This is a simple architecture for passing data between two microhoppers/robots. Robot 1 transmits its packet and waits for a response from robot 2. Robot 2, upon receiving the packet data, processes said data and eventually returns the new data and a semaphore indicating data ready. Robot 2 can then transmit back to robot 1 and the algorithm can begin again. If either robot does not receive a packet (i.e. the packet is dropped, corrupt, or lost entirely), then that robot retransmits the packet. This algorithm is detailed below in figure 3.

Figure 3: Transmission/Retransmission Architecture

Advantages:

· ensures that packets do not collide

· ease of coding (start timer after transmission, stop timer once next packet is received, restart timer if packet is not received in a timely manner)

Disadvantages:

· Poor use of communication bandwidth (both robots spend half the time waiting)

· Slow transmissions – the fastest RTT we ever found was 540 ms.

· Retransmitted packets can easily collide

Conclusion:

We implemented this algorithm, and the communication would work quite well. However, there is a large amount of waiting time when either robot is receiving no new data. The larger the delay between new received data, the worse off the control inputs. We needed to develop a more robot algorithm that allows for faster transmission speed, taking advantage of the waiting period to send a new packet.

Alternating Communication

To allow a packet to be ready as often as possible, we need to send packets at a rate of ½ the max round trip time (RTT). From the earlier communication algorithm, we learned that in our system we can achieve a max of 540 ms RTT. Thus, we need to transmit packets approximately every 300 ms. Since the microhopper cannot send and receive simultaneously, however we need to synchronize the two robot communications as illustrated below (see figure 4).

Figure4: Alternating Communication Architecture

Advantages:

· Maximum data transmission – the DSP is always processing a packet

· Maximum bandwidth usage – DATA is always being transmitted

· No retransmission necessary – every TIME_SEND milliseconds we send a new packet irregardless of what we have received. Thus, the packet send and receive are decoupled

Disadvantages:

· Processing time is merely an estimate, thus robot 2’s initial time offset before the first packet is also an estimate. This could cause simultaneous sends, causing packet collisions and corruption.

· Fast transmission could cause packet backup, causing the system to drop packets.

Conclusion:

Our project requires as many control packets as possible, and thus we decided this was the best communication algorithm. Alternating Communication provides the fastest and most reliable packet transmission, though packets are still lost due to the microhopper dynamics themselves.

Master/Slave Teleoperation System

Teleoperation is an important research problem with numerous issues like communication delays, controls, etc. It has many useful applications in space robot control, control over Internet, Networks, etc.

Mirror imaging

In this task one of the robots (Robot 1) acts as a “master,” carrying out various motions. The “slave” robot (Robot 2) is fed the master reference velocity (vref), turn and gripper position (open or close), through our custom Alternating Communication Protocol. The slave then imitates the master behavior, reversing the turn sign to act as a mirror image across a virtual mirror plane (See Figure 5).

Figure 5: Mirror Image Master-Slave System

· Planned Motion: Robot 1 is driven through a preset path and it grabs a can and stops, gripper is controlled with the help of optical encoder. Robot 2 follows similar motion as a mirror image and grips the can.

· Manual Control: Robot 1 is controlled with an optical encoder and driven though arbitrary paths and finally finds a can and grabs it. Robot 2 follows these arbitrary motions and finally grabs the can when robot 1 does.

Limitations and Constraints

· There is a communication time delay between the master and slave robots. The desirable RTT (Round Trip Time) for the communication between the Robots for such an application should have been in the range of 10 – 20 ms. But due to the constraints imposed by the current communication hardware structure the RTT currently never really goes below 300 ms.

· Due to limitation in the frequency of information communication, some data packets might be lost, so large accelerations are avoided to prevent important information loss.

· The two robots don’t have the exact same dynamics and might have some errors in their positions and velocities. In particular, they have different friction compensations and because of this aspect the tracking error can be significant.

Uses

· Such a systems can be used in cases where the exact layout of a building is known and a rescue mission type of job is to be performed, say in case of fire.

· It can also be used to test different radio communication strategies.

Conclusions

· The communication between master and slave worked efficiently with almost every data packet sent.

· Slave follows the master with good accuracy when accelerations are small.

· The mirror image will be exact if there is no communication delay and both robots have the exact same dynamics.

Spring/Mass/Damper Simulation

The Problem of Multi Robot Coordination Systems - A Brief Outline

One of the most interesting control and communications problems being researched currently is that of Multi Robot Coordination systems and their application to tasks such as coverage, exploration, surveillance, search and rescue, mapping of unknown or partially known environments, distributed manipulation and transportation of large objects.

There are various detailed and in depth questions which may be encountered in such a research area. But the primary objective in such a situation is that each robot in a large group of robots should be able to communicate its position and velocity to every other robot in a defined area of coverage (which may be a function of the communication systems being used). The other high level issue is that of coordinated control strategies of motion. The robots should be able to move with respect to each other in a pre-defined and controllable manner. In most common algorithms this is achieved by the use of potential fields. There are various intricate issues and considerations involved when one may want to define such a potential field. For example, there may be certain areas in the domain of interest where we want our robot to be and there may be others where want to avoid their presence. For such a case we can define a high positive potential for desirable areas and a negative one for the undesirable ones. In particular, when we need a coordinated motion amongst robots in a group, we need to define “attractive” and “repulsive” potential fields, so that the robots neither spread too far from each other nor do they come too close.

Thus, we have tried in this project to also look into issues pertaining to this interesting research topic from a very broad perspective.

Communication: The Inter Robot Alternating Communication Protocol developed as a part of this project is used to transmit the position, velocity, control signals, gains, parameters etc. Note that in this part of the project, “Bilateral Communication” has been implemented.

Coordination and Potential Functions: We have chosen a Spring-Damper model to define the “attractive” and “repulsive” potential fields between the robots.

The Task: To illustrate the Multi Robot Coordination and Communication System, (and to use more efficiently the “attractive” and “repulsive” potential fields defined using the springs and the dampers) we have chosen to simulate various cases from the classical mechanics problem of the Double Cart Spring Damper system. The system schematics from a mechanics point of view is given below in Figure 6.

System Physical Schematics

Figure 6: Classical Spring Mass Damper System used to define the potential field between Robots.

System Equations

Solving for the system equations using Free Body Diagrams we get:

ODE approximations

The ideal way to solve this problem in practice would have been to solve the equations in real time using the numerical Runga-Kutta-4 method. This was impossible, or at least not useful, for two reasons:

· Due to communication constraints, we already have a built in time delay of 300ms.

· The DSP cannot handle the computing load necessary to calculate the real-time solution.

Therefore, the system’s ODEs were not solved in real time. Instead, we utilize the fact that the “A” matrix of the given system is constant with time. Thus we use the well known formula from Linear Control Theory:

We use this solution in discrete steps to calculate the new state using the current state, made up of both robot’s positions and velocities via the wheel encoders. This results in the following:

We use the 4^th order Taylor expansion of exp(At), and thus the new input velocity is a simple function of the current position/velocity and the time step. Since Δt ~ 300 ms, this is justified.

Classical Spring Mass Damper

· Along with the VB interfaces, this module can be used to study the behavior of the system for different combinations on springs and dampers values.

· The system behaves as predicted by the physics of the system under the given constraints (for details about these constraint, scroll down).

Beat Frequency Generator

· The dampers are set to a value of zero. The inter robot spring is given a very high spring constant while the two springs between each robot and the walls are set to relatively low values. Depending on the various initial conditions provided to the system, we can generate various normal modes of the system. Careful tuning of the spring constants and initial condition results in the display of what is known as the “Beat Frequency”. (For details see the attached lecture notes in PDF. Click here to download them)

· The system behaves nicely to the changes in gains. It does come close to oscillating at the “Beat Frequency” but the phase difference cannot be maintained at Π/2 for a long time due to disturbances and constraints mentioned in the relevant section below.

Replication of Matlab Demo

· Setting the dampers as well as the side spring to zero we try to achieve results similar to the MATLAB simulation which can be viewed in one of the SIMULINK demos.

· One of the masses is constantly excited with a square wave whose frequency and amplitude can be changed using the VB interface. The other mass is coupled to this one with a spring of appropriate spring constant. The system really achieves what is simulated in the MATLAB demo under the given constraints. Note that in this we have a constant input to one of the masses and our system of equations will change. In particular, an integral term will have to be added to the exponential solution explained above. This has been implemented in the code using numerical integration and properties of the square wave generated.

Demonstration (notes and videos)

Notes

· The Communications Hardware does not permit us to have a Round Trip Time of greater than 300ms. The ideal value for the RTT should have been something like 10ms. At such a fast RTT we would have able to better simulate the situations. Also, there is a lot of interference in the present setup (Microhoppers) from other communicating robots moving around in the room, causing numerous packet corruptions and drops.

· The motor’s low bandwidth and small acceleration capacity make it difficult to simulate really chaotic and fast motion.

· Friction compensation can never be achieved completely. All equations derived in this part of the project assume absolutely no friction. But even with 100% friction compensation applied, we can never negate all friction.

· The two robots show significant difference in their operation. Not only is the friction compensation different, but the motors respond differently, the microhoppers respond differently, and all sensors are nowhere near identical. This hardware difference can be a major source of noise and jitter during operation.

Media

Screen Shots:

Picture 1: Visual Basic Interface for Multi Robot and Computer in the Loop Communication

Picture 2: Visual Basic Interface for viewing the Inter Robot Communication Packets’ Traffic

Picture 3: Visual Basic Interface for Mapping the Positions of the Robots

Picture 4: MATLAB SIMULINK system which has been replicated using Multiple Robots.

VIDEOS:

Video 1: Teleoperation Experiment. Click here to download movie.

Results and Reasoning: The video shows that we achieved very good results within the given drastic constraints. The Slave does follow the Master very well WITHOUT the help of any other sensor (vision etc). It could not position itself very accurately with respect to the can and so missed it by inches. This is expected to happen here because of the following:

The high Round Trip Time (RTT) , ~300 ms, creates a gradual build up in the offset between master and slave robots. In the absence of such a high RTT our Multi Robot Communication algorithm will work much more accurately and will enable near real time task executions.
The dynamics of the two robots are very different. The friction compensations are not same. The wheel wear from use over the semester is different. One of the wheels on the slave robot actually gets stuck at times (this was discovered by chance after the demo) due to dirt etc. These are other valid reasons for the offset which can be observed in the videos.

Video 2: Classical Spring Mass Damper. Click here to download movie.

Results and Reasoning: According to the video we have achieved desirable results. You can very well observe the video and figure out that the system is actually simulating the Spring Mass Damper model described above to a high degree of accuracy (in spite of the constraints mentioned under video 1).

Video 3: Beat Frequency Generator. Click here to download movie.

Results and Reasoning: The phenomenon of Beat Frequency is described in the PDF documentation which can be found above. The system indeed is displaying this phenomenon but we are not able to see it clearly since the phase difference is not exactly Π/2 and hence the beats are not clearly separated in this video. We have indeed observed beats (with a phase difference of around 80-85 degrees) during experimentation and development but we did not have a camera at that time to capture it. It seems to be pretty erratic because it depends on both the robots receiving the control simultaneously. But due to the constraints already mentioned we always have a big RTT which makes synchronization a question of trial and error. Thus the video has a phase difference of around 60-70 degrees and so the beats aren't as crisp as they have been observed to be at times.

Video 4: Replication of Matlab Demo. Click here to download movie.

Results and Reasoning: To understand the essence of this video the viewers are advised to see the relevant MATLAB simulation mentioned above. You will see that the double cart system, while vibrating, shifts right and left as a whole. Now if you see the video, you will find that our robots achieve that motion to a high degree of accuracy when one of them is being excited by a similar square wave signal and the other one, coupled by the spring, just follows the dynamics of the system. The two robots, while vibrating like a double mass spring system, shift in one direction over time (as can be clearly seen in the video). We have not included the motion back and in opposite direction because of the sheer size of the clip! Thus our communication and control algorithms seem to be working really good for this case despite the constraints mentioned.

Last updated : 2 AM, MAY 14, 2003

Code

To run our code:

Build code-composer code
Flash onto 2 robots
Using the dip switches, set one robot to “1” and the other to “2”
Press the reset button on each robot
Open up the VB interface and display
Choose mode, set associated parameters
Press the UPDATE button and wait
Once START is displayed, press to begin operation
Wait several seconds for robots to initialize

Download the zipped version of the source files for the Multi Robot Coordination / Communication Project