Environmental Explorer

Enex

Mittuniversitetet

Teachers in the lab

• Benny ThörnbergAssociate Professor in Electronics

• Najeem LawalAssistant Professor in Electronics

Mittuniversitetet

Our Vision

Feedback

CO2 Feedback

Feedback

80

9

HGKvicksilver

15

9

PFosfor

Environmental metrology Data visualization Innovation

Improvements

Climate change

Mittuniversitetet

Overall project assignment

• A wheel based robot is navigating autonomously along a rout defined by a set of waypoints,

• Geo-tagged environmental parameters should be acquired along this rout and stored for later reporting at base station,

• Battery power management should be developed. Is there energy enough in battery for another lap?

• A geographic map over the defined rout should be used for visualization of measured data.

Mittuniversitetet

Environmental parameters

• CO2 concentration in air

• Concentration of dust particles in air

• Air temperature and humidity

• Air pressure

• Sound level

• Sunlight radiation intensity

Mittuniversitetet

Robot navigation

• A GNSS receiver is used to traverse a rout as defined by a set of waypoints

• A spinning LIDAR sensor is used to implement obstacle avoidance

Start/Stop

Mittuniversitetet

Battery power management and communication

• Wifi and battery charging is available only at Start/Stop,

• Self learning of energy per lap. Can another lap be traversed on the energy left in battery?

• Measurement data is communicated to a central data server, once every lap at point of Start/Stop.

Start/Stop

Mittuniversitetet

Data visualization

• How to visualize data from measurements?

• Diagram showing measured parameters along the route?

• Sampling in spatial and time domain

Start/Stop

Mittuniversitetet

Four sub-projects

Groups of two or three students are working together in each one of the following four sub-projects

• Robot navigation

• Power management and communication

• Sensors

• Data collection and visualization

The common goal for these groups is to demonstrate Enex

Mittuniversitetet

Proposed project model

Requirement specification

Technical specification

DesignConstructionand coding

VerificationPrototype and technical documentation

Scientific report

Timeline

Steering group

This project model should be implemented for each of the sub-projects

Mittuniversitetet

Regular meetings with the steering group

• A steering group is coordinating development activities among the four subprojects to make sure that the common Enex goal is reached

• This group consists out of

• Teachers

• One student from each of the four sub-projects

• A 30 minutes meeting with the steering group is scheduled once every week for each sub-project.

• Development activities since last meeting is discussed and documented in a project log of minutes from all meetings.

Mittuniversitetet

Requirement specification

• A requirement specification captures the requirements a commissioner has defined for a product or prototype system to be developed.

• Several of the requirements are common for the whole Enex project while some can be specific for any of the four sub-projects

• Examples of such requirements are:

• Function

• Time-to-prototype and Time-to-market

• Maintainability

• Robustness and Safety

• Unit cost and NRE cost

• Size

• Performance

• Power, Energy and Battery operational time

Mittuniversitetet

Technical specification

• Divide the functionality into an hierarchy of smaller modules

• Specify how modules are dependent on each other, e.g. :

• Communication interfaces

• Source code interfaces

• Physical dimensions

• Connectors

• Modularity and well defined dependencies enables for parallel development activities. As for example, writing c++ code for interfacing with several sensors, each one measuring different environmental parameters is a work that can be scheduled in parallel. Defining software interfaces and specifying which physical port to use for which sensor becomes crucial for a successful demo of Enex in the end.

Mittuniversitetet

Prototype and technical documentation

• A working prototype of Enex should be demonstrated

• Technical documentation includes:

• Source code

• Drawings

• Descriptions for assembly and usage

Mittuniversitetet

Scientific report

• You should write a scientific project report

• Our hypothesis is that environmental parameter data can be acquired over large areas using a mobile wheel based robot

• The verification process in the project model should generate results to support our hypothesis and prove that it is true.

• Make sure that students individual contribution to the reported work is specified, hence who did what.

• For further guidance on how to write a scientific report, have a look at,https://youtu.be/1SsEpMxO_AA

Mittuniversitetet

Seminar and demonstration of Enex

• A seminar is scheduled at the end of the course

• Students in each sub-project should make an oral presentation of their work.

• The seminar is directly followed by a demonstration of Enex

Mittuniversitetet

Course aims

• This course provides the student with a deeper knowledge in embedded sensor systems where non-functional design constraints such as energy, communication, performance, cost and integration in the surrounding environment must be considered.

• In addition to collecting and using information from technical literature and related work in the field, the student should be able to model, simulate and implement a design according to requirement specifications.

• Students will be trained to work in teams together with other students who are focusing on other fields of embedded sensor systems in related projects.

Mittuniversitetet

Course objectives

After completion of the course the student should be able to:

• analyze complex problems where a clear optimal solution is missing,

• demonstrate the ability to formulate solutions to a given problem in a specific area of embedded sensor systems,

• based on specifications model, simulate and implement the proposed solution to the given problem.

Mittuniversitetet

Examination

• 7.5 hp, P101 Project with documentationGrade A, B, C, D, E, Fx and F where A-E represent pass grade and Fx and F represent fail grade.

• 1.5 hp, R101 Oral presentation and written reportGrade Pass or Fail

Mittuniversitetet

Scheduled activities

Week Lecture Lab Project meeting

Seminar

45 X X

46 X

47 X

48 X

49 X

50 X

51 X

1 X

2 X

• Table shows pre-scheduled teaching activities

• Prepare a first version of the requirement specification for the first project meeting

• 25 minutes meetings are planned for each one of the four sub-projects

• In addition to these activities, you need to spend enough of working hours together with your project members in lab

Mittuniversitetet

Short introduction to Robot Operating System - ROS

• ROS is an open-source, light-weight, meta-level operating system for the control of any robot

• A set of tools, libraries and conventions

• Developments at Stanford University led to a first release of ROS 0.4 in 2009

• www.ros.org is a vibrant community of contributors

• Becoming de facto standard for robot programing

• Comes with the permissive license, BCD

Press photo from www.willowgarage.com

Mittuniversitetet

ROS Master

• All other nodes are registered at the ROS Master upon start

• The purpose of a ROS Master is to handle all inter-node communication

• Start the Master at command prompt. Type,

$> roscore

ROS Master

Mittuniversitetet

ROS Nodes

• A smaller single-purpose program for the management of services related to a robot, e.g. management of a motor or a sensor

• Sets of nodes are organized in a packages

• Nodes get registered at the ROS master at start

• Start a ROS node with command,$> rosrun name_of_package name_of_node

• Nodes can run distributed on different processors in a robot system

ROS Master

Node A Node B

Mittuniversitetet

Communication between ROS Nodes

• Nodes communicate with each other by passing messages over a topic

• A topic is a stream of messages that typically one node is publishing and one or more nodes are subscribing to

• When a node receives a message on a topic it is subscribing to, a callback function in that node starts a service routine or a simple function e.g. change speed of motor

• Messages are thus used to remotely invoke services on other nodes

Node A Node B

topicPublication Subscription

Service invocation

Message

Mittuniversitetet

Messages

• Data structure defining the type of topic

• A nested structure of integers, floats, Booleans, strings

• Defined by an hierarchy of .msg files

Node A

topicPublication Subscription

Message

Header header

Twist twist

TwistStamped.msg

Message definition

Node B

Mittuniversitetet

Messages - example

• TwistStamped message used for sending information about linear and angular speed

Header header

Twist twist

TwistStamped.msg

Vector3 linear

Vector3 angular

Twist.msg

float64 x

float64 y

float64 z

Vector3.msg

uint32 seq

time stamp

string frame_id

Header.msg

string data

String.msg

time data

Time.msg

uint32 data

float64 data

Uint32.msg

Float64.msg

Mittuniversitetet

Example – Drive robot forward or backward

• A topic called cmd_vel has one publisher and one subscriber, Controller Node and Motor Node

• Controller Node is sending messages of type geometry_msg/Twist to the Motor Node

• Motor Node is reacting on those messages by changing linear speed accordingly

• This is a one-way communication without any responses being sent back to Controller Node

Controller Node

Topic: cmd_vel

Publication Subscription

Message

geometry_msg/Twist.msg

Message type

Vector3 linear

Vector3 angular

Motor Node

Mittuniversitetet

Example – Controller Node

int id = 0;ros::Publisher action_pub;geometry_msgs::Twist set_vel;

int main(int argc, char **argv) {

ros::init(argc, argv, "drive_my_rosbot_node");ros::NodeHandle n("~");ros::Rate loop_rate(50);action_pub = n.advertise<geometry_msgs::Twist>("/cmd_vel", 1);set_vel.linear.x = 0;set_vel.linear.y = 0;set_vel.linear.z = 0;set_vel.angular.x = 0;set_vel.angular.y = 0;set_vel.angular.z = 0;action_pub.publish(set_vel);

}

Body of program

Twist messages to be published

Name of controller node

Create a publisher object attached to topic /cmd_vel using node handler

Define first command for setting initial speed values

Publish message on topic /cmd_vel

Run main program loop at 50 Hz

Mittuniversitetet

Example – Body of program for Controller Node

Process incoming messages

char key = ' '; while (ros::ok()) {

key = getchar();switch(key) {

case 'f': // Faster forwardset_vel.linear.x = set_vel.linear.x + 0.1;break;

case 's': // Slower forwardset_vel.linear.x = set_vel.linear.x -0.1;break;

case 'q': // Stop and exit programstd::cout << "Good Bye" << std::endl;set_vel.linear.x = 0;set_vel.angular.z = 0;action_pub.publish(set_vel);return(0);break;

} // End of switch action_pub.publish(set_vel);ros::spinOnce();loop_rate.sleep();

} // End of while Delay to fulfill specified loop rate

Increase linear speed parameter x with 0.1 if “f” has been pressed

Decrease linear speed parameter x with -0.1 if “s” has been pressed

Publish message on topic /cmd_vel

Mittuniversitetet

Services

• ROS uses a simplified service description language ("srv") for describing ROS service types

• It is a mechanism for remote procedure call that enables request/response communication between requesting and serving nodes

• A service description file .srv, consists of request and a response message types separatedby '---'.

• Any two sets of .msg files concatenated together with a '---' are a legal service description

• You are not allowed to embed another .srv inside of a .srv.

Mittuniversitetet

Services - Example

# This service requests that a camera stores the given CameraInfo

# as that camera's calibration information.

#

# The width and height in the camera_info field should match what the

# camera is currently outputting on its camera_info topic, and the camera

# will assume that the region of the imager that is being referred to is

# the region that the camera is currently capturing.

sensor_msgs/CameraInfo camera_info # The camera_info to store

---

bool success # True if the call succeeded

string status_message # Used to give details about success

SetCameraInfo.srv

Mittuniversitetet

Rosbot

• Rosbot is an autonomous robot platform

• It was developed as a crowd-founded Hackadayproject,https://hackaday.io/project/21885-rosbot-autonomous-robot-platform

• Programming is done using ROS

• Rosbot has a rich selection of extension I/O on its rear panel allowing for connection with sensors and actuators

Mittuniversitetet

Rosbot Hardware Overview Wifi antenna connector

USB connected to a SBC

HDMI output from SBC

USB used for loading flash and debugging of CORE2

Connect to battery charger

hExt hSens4Servo outputsTOF

distance sensors

On/Off

CORE2 board with Arm Cortex microcontroller STM32F4

Raspberry Pi or Tinker board SBC

Both CORE2 and SBC can run ROS nodes

Mittuniversitetet

Rosbot hExt connector

hExt pin Software name Default function Alternate function

1 hExt.pin1 GPIOexternal interrupt input

ADC converter

2 hExt.pin2 GPIOexternal interrupt input

ADC converter

3 hExt.pin3 GPIO - ADC converter

4 hExt.pin4 GPIO - ADC converter

5 hExt.pin5 GPIO - ADC converter

6 hExt.serial.pinRx UART RX GPIO -

7 hExt.serial.pinTx UART TX GPIO -

8 hExt.spi.pinSck SPI SCK GPIO -

9 hExt.spi.pinMiso SPI MISO GPIO ADC converter

10 hExt.spi.pinMosi SPI MOSI GPIO ADC converter

11 hExt.i2c.pinSda I2C SDA GPIO -

12 hExt.i2c.pinScl I2C SCL GPIO -

13 -+5V power supply output

- -

14 - GND (0V) - -

15 -+Vin (6-16V) power supply output

- -

16 - GND (0V) - -

17 -+Vin (6-16V) power supply output

- -

18 - GND (0V) - -

19 -+Vin (6-16V) power supply output

- -

20 - GND (0V) - -

1 3 5 7 9 11 13 15 17 19

2 4 6 8 10 12 14 16 18 20

. . . . . . . . . .

. . . . . . . . . .

Mittuniversitetet

Rosbot hSensor connector

1 3 5

2 4 6

. . .

. . .

hSensor pin Software name Default function Alternate function

1 hSensX.pin1 GPIOexternal interrupt input

ADC converter

2 hSensX.pin2 GPIO

3 hSensX.pin3 GPIO

I2C_SCL (in hSens1 & 2) UART_TX (in hSens 3 & 4) no alt. function (in hSens 5 & 6)

4 hSensX.pin4 GPIO

I2C_SDA (in hSens 1 & 2)UART_RX (in hSens 3 & 4) no alt. function (in hSens 5 & 6)

5 -+5V power supply output

6 - GND (0V)