GuruBhakts: Gesture based swarm approach to control robots on WSN


GuruBhakts, are wireless sensor nodes based Robots, showcasing the Leader-Followers (Guru-Bhakts) behavior on the wireless sensor network. The project was submitted as the final project for ESE519: Real-time and Embedded systems Course. The Project was developed by Jitender Bishnoi, Rahul Khosla and I under the guidance of Professor Rahul Mangharam. We had great support from mLab: Embedded systems lab with resources for the project.

The approach adapted to implement a Leader-follower behavior on the robots which are controlled by hand gestures (wireless node implemented with accelerometer) has been briefly described here.

FireFly wireless sensor node was used for the application, running Nano-RK a real time sensor operating system and implementing the RT-Link network protocol. The purpose of the paper is to understand the implementation of the swarm application on the FireFly and devise a protocol with minimum packet-loss. The method adapted considered various aspects including the hardware design, measuring the distance covered by the robots, maintaining the right direction in all robots, determining the turn angle and maintaining a fixed distance between robots.

The GuruBhakts application can be viewed as a first step in automatic navigation multi robot navigation system. The Guru a.k.a Leader directs the Bhakts a.k.a Followers to behave in the similar manner and follow the actions of the Guru but also considering the distance between them. This approach makes the robot work in a train like manner, only the bogies are wirelessly connected to the engine. We prefer to call this bunch of robots at the robot army. The future use of this system can be used to direct group of robots into hazardous and complex environment while controlling only one of the robot.

The command flow for the system can be reflected by the diagram shown. The MahaGuru (FireFly Node held by user) collects data from the user’s hand motion or gesture which determines the direction of the Guru. Forward Tilt of the node makes the Guru go forward. The vertical position of the MahaGuru will send the stop command to the robot. The Guru receives the command from the MahaGuru and forwards it to the Bhakts. The Guru and Bhakts start of at the same location after a predetermined delay and thus follow the same path.

Hardware:

GuruBhakts hardware can be subdivided into following categories: Controller, Wireless Module, Actuator, Drivers, Feedback circuit and Power supply. The Controller and Wireless Module are bundled together on to the FireFly platform. GuruBhakts anatomy can be defined as shown in the figure. GuruBhakts use Parallax’s continuous rotation servos and Nu-Botics wheel watcher for Actuation and feedback. The continuous rotation servos were selected due to their high torque, ease of use and installation. These servos do not require any external driving circuitry. However, while implementing these on with the FireFly , we were connecting the servo across the led connected to the port E.4 and E.5 of the microcontroller. These resulted in a DC shift of 2v at the output (input to the servos). Thus we implemented a simple driving circuit in between the controller and the servo consisting of a high pass RC filter with corner frequency just below 50Hz (considering the 50Hz/ 20ms signal frequency of the servos signals).

The wheel watcher connected to both the wheels of the Robots provided us with a square wave pulse, whose frequency varied with the variation in speed of the wheel. These signals were used at the timer interrupt of the node to determine the speed of the wheels and make correction to compensate for the unequal speed of the servos.

Controlling the Servos:

The servo motors require a PWM signal of the fixed format. The PWM signal should be having a period of 20ms and ON time of 1 to 2 ms as shown in the figure

However, for continuous rotation servo, the direction and speed of the servo is controlled by the ON time width. The width of 1.5 ms turns the servo OFF. Varying the width towards 2ms will make the servo rotate clock-wise and varying it towards 1ms makes it rotate counter-clockwise. However, the speed can only be varied 1.3ms to 1.5ms and in the opposite direction from 1.5ms to 1.7ms range. The pulse with exceeding 1.7ms or below 1.3ms results in servos moving at full speed.

Decoding the Encoder:

The Wheel Watcher by Nu-Botics outputs a 32 clock per servo rotation output on each output channel. It also outputs a directional and clock output, which can be further used to determine the direction and precise rotation of the servo. However, we are currently ignoring the direction as both servos will be rotating in opposite direction.

Communication Protocol:

We have used RT-Link as the communication protocol. Some problems faced initially with RT-Link are listed below.

1)    Initially we faced normal issues like dropped messages. But using multiple transmissions (2 in our case) per frame of 32 slots helped removing the problems.

2)    Although communication got better after sending messages in 2 slots per frame, but we were still getting the problem of network freeze. And we were getting “Task reserve violated”, the problem of network freeze was quite frequent.  Once the network was lost, we had to reset the all the nodes. This was solved after setting the time in “TaskOne.cpu_reserve.secs” and “TaskOne.cpu_reserve.nano_secs” to zero.

3)    Transmission and reception interfered with interrupt waves generated for servo motors, although we were hardware interrupt generation. On debugging we found “nrk_wait_until_next_period()” and “rtl_wait_until_rx_or_tx()” functions were the reason behind this interference. Deleting these functions resulted in smooth wave generation and no resets.

Direction sensing of MahaGuru

Task of MahaGuru was work like a joystick, i.e., to control the movement of leader bot. It should work like – On tilting it to left, the robot should move leftward and similar in case of other directions. To achieve this inbuilt accelerometer used in the node was used. Change in tilt of node produces different values along the 3-axis. Nano-RK API provides support for retrieving the configuration of a node’s accelerometer in x,y and z axis as a triplet of uint_16. These values of 3-axis are then sent to leader bot. As mentioned earlier same message is sent twice in frame to increase redundancy.  In the Guru we map the range of values for each desired position i.e. left , right, forward, backward tilt and also the for stopping the bot. Upon deciding the direction first we send the same to Bhakts robots and also set the corresponding values for generation of hardware interrupt waves. Guru node forwards it to the Bhakts while maintaining the redundancy, all through care is taken that duplicate messages are rejected.

GuruBhakts in News:


Advertisements

Tags: , , , , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: