0% found this document useful (0 votes)
56 views

Lecture10 - Interfacing Hardware

This document discusses software engineering considerations for interfacing hardware in robotics. It addresses main issues like generating complete interfaces and integration methods. Standard interfaces can provide common services through object hierarchies. Sensors require modeling state and subscription models. Actuators involve modeling state, control models, and timing requirements. Examples of interfacing sensors like GPS and cameras are provided. In summary, interfaces require abstracting needed data and timing while adopting existing models when possible. Robot control can be achieved at rates up to 500Hz with minimal effort.

Uploaded by

Balaji Rajendran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
56 views

Lecture10 - Interfacing Hardware

This document discusses software engineering considerations for interfacing hardware in robotics. It addresses main issues like generating complete interfaces and integration methods. Standard interfaces can provide common services through object hierarchies. Sensors require modeling state and subscription models. Actuators involve modeling state, control models, and timing requirements. Examples of interfacing sensors like GPS and cameras are provided. In summary, interfaces require abstracting needed data and timing while adopting existing models when possible. Robot control can be achieved at rates up to 500Hz with minimal effort.

Uploaded by

Balaji Rajendran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Software Engineering in Robotics

Interfacing Hardware

Henrik I. Christensen [email protected]

Outline

Introduction
What are some of the main issues?
Service Considerations
Some of the details
Summary

Introduction

Robotics is all about interaction with the world


Need to consider interface design for sensors
and actuators

What are the typical sensors?


What are the typical actuators?
How can we do integration of mechanisms?

Consideration of modularity / component


design

What are good generic interfaces?


How does timing impact your design?

Design Considerations

Use consistent name conventions


Think about time/pose stamps
Consider links options
Consider logical variables names
What are good units?

Main issues in HW interface

Generation of a complete interface?


Is there a need to utilize proprietary
code/libraries?

What are possible methods for integration?

We will cover this in later lecture!


Generic code vs design of a proxy interface

Utilization of generic device models

Mobile Robot Differential Drive Systems


Ranging sensors Scanner, Pinger,
Imaging Sensors Generic Camera
Manipulators Scara vs Full Articulated Arm

Using standard interfaces

Through object hierarchies it is possible to


provide standardized services

Using similar naming conversions enables


easy adoption

Differential Drive Robot Pioneer, Roomba,

A more general issue to always consider

Careful consideration of what is visible?

Are there multiple models for access?


Such as Joint and Cartesian control of a robot

Strategy for design

What does the interface look like?

Side Effects?

Variables?
Access? Control Models / Feedback
Logging?
Automated recovery from errors?
State variables (not visible)

Control Strategies

Monolithic vs Multi-Agent Access / Control


Critical Resources / Access Models

Interfacing to a comms robot

RDS includes a standard Serial Interface

Consider the partitioning of the service

Allows you to abstract away the hardware


handshake

A mega service or a number of related services


Ex: Pioneer ATX interface with drive and sensors
integrated or Pioneer Drive Service, Pioneer Sonar
Service, .

Analysis

Mega services easier to deploy. Harder to reuse


Distributed services easier to design subscription
model, easier to extend over time, harder to
integrate

Sensor Models

Careful analysis of State

How do you want to access data?

As a full data sample (ex laser scan)


As individual readings (ex sonar)

What is the subscription model?

Push of data when new data arrives


Subscription for Pull data services?
Do you want to set up custom triggers (bumper,
)

Adjust State, Connection


Characteristics/PortSet

Use examples in the RDS samples folder to

Actuator Models

Consider

State what do you need to control? What feedback?


PortSet what is the underlying control model?

Partitioning What are the timing requirements?

State

Is control point-to-point, smoothing, trajectory planner

Is there a need for joint and Cartesian Control?


What feedback/encoder/Cartesian data should be returned?

Control

RDS can accommodate control rates up to ~500Hz on a


regular Windows 7 computer (1GHz, )
What data / control rate is needed? Should trajectory
smoothing be performed by the service or on the robot?

Examples

Microsoft GPS

Great example of use of the Serial Service


Check \RDS-R3\samples\sensors\MicrosoftGps

WebCam

Generic Interface that fits most cameras


Check the ..\RDS-R3\samples\sensors\WebCam

Summary

What is a good abstraction for your interface?

What data do you need access to?


What are timing requirements?
What control model is needed?

Is there an existing model you can adopt?

Robot control at rates up to 500Hz can be


achieved with minimum effort

Check the diverse set of code samples on the


net, such as CodePlex, ProRDS, .

Acknowledgement

This series of lectures has been developed


with generous support from the Microsoft
Corporation as part of the project Software
Engineering in Robotics Contract # 113873.
The support is gratefully acknowledged.

You might also like