Final project presentation

CS 7630

April, 27th 2015

Students : Chouaieb Nemri - Zakaria Fadli

Supervisor : Prof. Cédric Pradalier

2

OUTLINE

Autonomous Robotics

• The big picture

• The Explorer

• The State Machine

– ...

– Docking/Undocking

– Battery

• Moving to the turtlebot

2

3

The big picture

What do we know ?

4

The big picture

What does a Robot need to be Autonomous ?

An autonomous Robot combines the elementary behaviours

we dealt with in CS 7630 to gain information about the

environment to interact with it for an extended period without

human intervention

What is the final Projects mission?

● Make the robot explore the second floor and map the wifi

signal while monitoring its laptop and base batteries’

status.

● Interrupt the mission and go to the docking station if

batteries go below a predefined threshold

The Explorer

What did we add to our occgrid_planner?

The Explorer

Exploration tradeoff - Coverage radius size

The State Machine

Why do we need a state machine?

● An autonomous system has different behaviours

● It should take decisions and combine behaviours based

on information collected from the environment.

● A state machine is a very suitable approach for such a

problem

The State Machine

A finite state machine is a mathematical abstraction used

to design algorithms. In simple terms, a state machine will

read a series of inputs. When it reads an input it will

switch to a different state. Each state specifies which

state to switch for a given input.

Different tools for state machines on ros:

SMACH TASK MANAGERSimple State

Machine Node

9

- One Node for the state

machine

- The State machine node is

executed synchronously on

a callback of a timer.

- Every “slave” Node launched

trough an enable signal

- Those enable signals are

stored in local variables for

every slave node of the

machine, and used as test.

- slave nodes are also

executed on timers too, but

they do not execute any

code when their enable is

off.

The State Machine - Structure

10

The State Machine - Implementation

// Transitions update

T1 = state_charging && (Map_UnComplete && ((

battery_laptop>batteryL_th) && ( battery_robot>batteryR_th)));

T2 = state_undocking && undocked;

T3 = state_exploring && (Map_Complete || ((

battery_laptop<batteryL_th_down) || (

battery_robot<batteryR_th_down)));

T4 = state_gohome && Home_reached;

T5 = state_docking && Docked;

// Desactivating precedent states

if (T1) state_charging=false;

if (T2) state_undocking =false;

if (T3) state_exploring=false;

if (T4) state_gohome=false;

if (T5) state_docking=false;

// Activating next states

if (T5) state_charging=true;

if (T1) state_undocking=true;

if (T2) state_exploring =true;

if (T3) state_gohome=true;

if (T4) state_docking=true;

11

// Output assignment

std_msgs::Bool sm_enable;

if (state_charging_prev != state_charging){

sm_enable.data=state_charging;

pub1_.publish(sm_enable);

ROS_INFO("charging switch");

}

if (state_undocking_prev != state_undocking){

sm_enable.data=state_undocking;

pub2_.publish(sm_enable);

ROS_INFO("undocking switch");

}

if (state_exploring_prev != state_exploring){

sm_enable.data=state_exploring;

pub3_.publish(sm_enable);

ROS_INFO("exploring switch");

}

if (state_gohome_prev != state_gohome){

sm_enable.data=state_gohome;

pub4_.publish(sm_enable);

ROS_INFO("gohome switch");

if (( battery_laptop<50 )&&(state_gohome)) ROS_INFO("battery down ");

}

if (state_docking_prev != state_docking){

sm_enable.data=state_docking;

pub5_.publish(sm_enable);

ROS_INFO("docking switch");

}

And all this is executed at each timestep

Undocking

12

● Move backward while

constantly computing

distance from the initial

point.

● Finish the task and start

exploring when a distance

threshold is reached (The

Machine state take care of

that)

Explorer and Go home

● The explorer publishes it exploration goals to the target

callback only when the exploration state is enabled.

● The explorer saves and publishes its position when first

executed, so it’s the position of the robot exactly when it’s

completely undocked.

● This home_goal position is published to the target .

● The target callback function is called for any of those two

goals.

● The path follower, when indicating that he reached its

goal, is conditioned by which state is active on the state

machine, to know if we reached home or just an

exploration point.

Battery

Simulating the battery effect

Docking

● When home, start rotating until the alvar marker is in the

center of the camera’s image.

● Move forward until reaching a distance threshold

● Not working! IndividualMarkerNoKinect can’t detect the

marker

16

The final result (video)

https://youtu.be/Q-WCuvTpAEM

Moving to the turtlebot

What would we have delt with ?

● Localisation would have been less stable

● Real world imperfections, noise

● Different velocity constraints / environment dimensions

● Less accurate odometry?

● Adapting launchfiles

What would we have done for wifi mapping ?

● One callback for all the signals that :

○ personnalises filenames with the signal IDs.

○ Updates each file with current_x, current_xy and signal

power when recieves a msg.

○ we would have created the maps offline using MATLAB

Conclusion

Final project

CS 7630

● Different tasks : Explorer, GoHome, Docking, Undocking ..

● Statemachine

● Moving to the turtlebot

● Thank you for your time and availability

● & especially for your enthusiasm

19

Questions ?

19

Thanks for your attention