0% found this document useful (0 votes)
43 views54 pages

More On Embedded Systems Mobile Robots and  - Mobile ... - EPFL

This document discusses embedded systems programming concepts. It explains that embedded systems have real-time constraints due to hardware limitations and interacting with the environment. Programming embedded systems requires managing resources like memory, computation and energy. Techniques are needed to make optimal trade-offs between these constraints. Improper software design can have catastrophic consequences, as shown by the Ariane 5 rocket explosion caused by a coding error.

Uploaded by

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

More On Embedded Systems Mobile Robots and  - Mobile ... - EPFL

This document discusses embedded systems programming concepts. It explains that embedded systems have real-time constraints due to hardware limitations and interacting with the environment. Programming embedded systems requires managing resources like memory, computation and energy. Techniques are needed to make optimal trade-offs between these constraints. Improper software design can have catastrophic consequences, as shown by the Ariane 5 rocket explosion caused by a coding error.

Uploaded by

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

Signals, Instruments, and Systems – W8

More on Embedded Systems


– Mobile Robots and
Embedded Software
Outline
• General concepts in robotics:
y, controllers,, control loop
autonomy, p
• The e-puck miniature robot
• General architecture
• Some hardware features
• Embedded
E b dd d systems
t programming
i
• Perception-to-action loop
• Interrupts
• Scheduling
• Operating system and device drivers
Generall C
G Concepts
t ffor
Robotic Systems
Open-Loop
Open Loop vs.
vs Closed-Loop
Closed Loop Control
• Open-loop
p p example:
p An heatingg system,
y , pprogrammed
g to
turn on at set times: it does not measure temperature as a
form of feedback. Even if the sun is warming the room,
the heating system would activate on schedule, wasting
energy.

• Closed-loop example: An heating system which adjust


th heating
the h ti time
ti as a function
f ti off theth measuredd
temperature. If the sun is warming the room, the heating
system will be activated less often than in a rainy day.
day
What is a Controller?
• [From wikipedia] In control theory, a controller is a
device which monitors and affects the operational
conditions of a given dynamical system. The
operational conditions are typically referred to as
output variables of the system which can be affected
by adjusting certain input variables.

• Example, the heating system of a room:


– Sensing:
S i t
temperature
t probe
b
– Controller: thermostat
– Actuation: heater
– Dynamical system: room
What is a Controller?
• In this course (embedded systems), a controller is a
piece of software which monitors and affects the
operational conditions of a given dynamical system
consisting of the device hardware and the environment.

• Example, the heating system of a room:


– Sensing: temperature probe
– Controller: algorithm for controlling the heater based on the
measured temperature
– Actuation: heater
– Dynamical system: room + microcontroller-based
microcontroller based device
Perception-to-Action Loop
sensors actuators
Perrception

Action
Computation
(controller)

A
Environment

Note: real-time aspect emphasized!


Autonomy
• Different levels/degrees of autonomy
– Energetic level
– Sensory,
Sensory motor
motor, and computational level
– Decisional level
• Needed degree of autonomy depends on
task/environment in which the unit has to operate
• Environmental
i l unpredictability
di bili is i crucial:
i l robot
b
manipulator vs. mobile robot vs. sensor node
Autonomy –
The Impact of Controllable Mobility

Human-Guided
Task Complexity Robotics

State of the Art in


Mobile Robotics

Research
Autonomous
Robotics Industry

Autonomy
y
The e-puck miniature
robot
S l t d andd re-elaborated
Selected l b t d slides
lid from:
f
Microinformatique
q

I t d ti tto th
Introduction the e-puck
k robot
b t
Francesco Mondada
Robotics Systems Laboratory
IMT - STI - EPFL
The ee-puck
puck Mobile Robot
Main features
• Cylindrical, Ø 70mm
• dsPIC processor
• Two
T o stepper motors
• Ring of LEDs
• Many sensors:
9 Camera
9 Sound
9 IR proximity
9 3D accelerometer
• Li-ion accumulator
• Bluetooth wireless communication
• Open hardware (and software)
The e-puck
e puck Open Hardware License
The specifications of the e-puck mobile robot are "open source hardware".
You can redistribute them and/or modify them under the terms of the e-puck
Robot Open Source Hardware License as published by EPFL. You should
have received a copy of the EPFL e-puck Robot Open Source Hardware
Li
License along
l with
ith these
th specifications;
ifi ti if not,
t write
it to
t the
th Ecole
E l
Polytechnique Fédérale de Lausanne (EPFL), Industrial Relations Office,
Station 10, 1015 Lausanne, Switzerland.

These specifications are distributed in the hope that they will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For
more details, see the EPFL e-puck Robot Open Source Hardware License.
Mechatronic Hardware
Overview
e-puck Block Schema
Computation
and memory
Communication
Actuators
Sensors
e-puck Overview
Speaker
IR receiver
((remote control))
Reset
Accelerometer
Mode selector
RS232
Programming and Ring of LEDs
debug connector
IR proximity
i i
ON-OFF sensors
microphones
p
CMOS camera
Wheels with
stepper motor Li-Ion accumulator
ee-puck
puck Mechanical Structure
e-puck Electronics
(typical routing report produced by the EPFL PCB workshop)
e-puckk Electronics:
El t i SampleS l Schematics
S h ti
e-puck Electronics: Layout (4 Layers PCB)

mask top bottom mask

inside
PIC/dsPIC Family
from www.microchip.com

Microcontroller
on the
h e-puckk
DSP and Specialized Variants
• dsPIC is a family of chips combining microcontroller and Digital
Signal Processor (DSP) structure and features

• For each dsPIC family member there are three variants:


• General purpose (codec interface)
• Motor control and power conversion (Pulse Width
Modulation generator and encoder reading)
• Sensor processor (minimal variant)
dsPIC Family Variants

ee-puck
puck
microcontroller
Programming
g g Real-Time
Embedded Systems
Embedded systems
ƒ Programming embedded systems is all about resource
management, i.e. dealing with delays and time constraints
imposed by the environment and limitations of the hardware
(memory, computation, energy, communication bandwidth).
ƒ When pprogramming
g g ((or simply
p y using)
g) an embedded system,
y , yyou
must bear in mind its limitations and find appropriate
techniques for dealing with them.
ƒ E
Energy, memory and d computation
t ti are often
ft very limited
li it d andd
precious in real-time embedded system applications.
ƒ Often
Often, you need to find the optimal trade
trade-off
off between
computation, memory and communication.
ƒ Fortunately, computer and electronic engineers have developed
a lot of useful techniques to perform these trade-offs.
Programming Embedded Systems
ƒ Modern embedded systems have increasing
software complexity.
ƒ Some applications may be critical and
improper software design can cause real
catastrophes!
ƒ Ariane 5 explosion: a 64 bit floating point
number tracking the horizontal velocity of the
rocket was converted to a 16 bit signed integer.
The number was larger than 32,767, the largest
integer storable in a 16 bit signed integer, and
thus the conversion failed:
double h_v = horizontal_velocity();
y()
short int h_v2 = (short int) h_v;

ƒ Cost of these two lines of wrong code? The


destroyed
y rocket and its cargo
g were valued at Ariane 5 explosion
p on June 4,,
US $500 million. The development cost of the 1996. No human casualties (except
rocket was US $7 billion. for the software engineer who has
been fired from ESA).
Real-Time
Real Time Issues in Embedded
System
y Programming
g g
Real-time: definition
ƒ A system is said to be real-time if the total correctness of an
operation depends not only upon its logical correctness, but also
upon the time in which it is performed (Wikipedia).
(Wikipedia)
ƒ One can distinguish two types of real-time systems:
ƒ Hard real-time systems:
y the completion
p of an operation
p after its
deadline is considered useless (ultimately, this may lead to a critical
failure or the destruction of the system).
ƒ Soft real-time systems:
y the completion
p of an operation
p after its
deadline decreases the service quality (e.g., dropping frames in a
video streaming).
ƒ Warning: a real
real-time
time system is not necessarily a high
high-performance
performance
system, and vice versa!
ƒ An e-puck can be a real-time system (if properly designed), but it will
never be a high-performance
high performance system!
Real-time: it matters
time

Read and digitalize Calculate updated roll, Update flaps and


Filter data
instruments data yaw and pitch throttle

This is an example of hard


real time embedded system
real-time
Perception-to-Action loop

sensors actuators

processing time
analog-digital
Perceptiion

Action
n
conversion time actuator delay
Computation

sampling rate propagation time


Environment
Perception-to-Action delay

Sideairbag g in a car: p
perception-
p
to-action delay < 10 mSec

Wing vibration in a plane:


perception-to-action delay < 5
mSec

TIK Lectures - Embedded Systems, ETHZ


http://www.tik.ethz.ch/tik/education/lectures/ES/
“Super” loop software architecture
ƒ The super loop or endless loop is void main() {
// prepare for task X
often required because we have no X_init();

operating system to return to at // super l


loop
the end of the program! while (1) {
X(); // perform task X
wait(35); // active wait
9 Simple,
p , efficient and pportable! }
}
2 Timing is inaccurate!
2 High power consumption!

ƒ Assume that you want X() to be executed at precisely 18kHz (T


= 55µs).
ƒ You know that X() duration is about 10µs. Therefore, you wait
35µs (using a calibrated active loop).
ƒ This type of software architecture does not guarantee accurate
timing.
Solution: interrupts
ƒ An interrupt is a special signal that triggers a change in execution, i.e. a
call to a subroutine which is usually referred to as an interrupt service
routine (ISR).
(ISR)
ƒ The interrupt does not wait for the current program to finish. It is
unconditional and immediate.
ƒ Interrupts are very useful for interacting with hardware devices, but
there are also software interrupts, which are triggered by a program.
ƒ Interrupts are also very useful when coupled with a timer.
timer They allow a
function or subroutine to run periodically with an accurate timing.
ƒ Another benefit of using interrupts is that in some microcontrollers you
can use a wake-from-sleep interrupt. This allows the microcontroller to
go into a low power mode, and be wakened later on by a hardware
interrupt.
Interrupt software architecture
void _ISRFAST _T1Interrupt(void) {
IFS0bits.T1IF = 0; // clear interrupt flag
Interrupt Service Routine
X(); // perform task X
}

void InitTMR1(void) {
T1CON = 0;
T1CONbits.TCKPS = 0; // prescaler = 256
TMR1 = 0; // clear timer 1 Interrupt set-up and
PR1 = (MILLISEC/18.00); // 18KHz interrupt (T = 55 us)
initialization
IFS0bits.T1IF = 0; // clear interrupt flag
IEC0bits.T1IE = 1; // set interrupt enable bit
T1CONbits TON = 1;
T1CONbits.TON // start Timer1
}

void main() {
// initialize Timer 1
InitTMR1();

sleep(); // go to sleep, waiting for interrupt Sleep forever, waiting


for interrupt
}
Typical execution scheme
main() sleep sleep sleep sleep sleep sleep
ISR X() X() X() X() X()

21µs 34µs 21µs 34µs 21µs 34µs 21µs 34µs 21µs 34µs

INTERRUPT! INTERRUPT! INTERRUPT! INTERRUPT! INTERRUPT!

Timer 1 Timer 1 Timer 1 Timer 1 Timer 1 Timer 1 Timer 1

55µs 55µs 55µs 55µs 55µs

ƒ The main loop gets executed, but the only thing it does is to put the
microcontroller in sleep mode.
ƒ In sleep mode, timers and hardware interrupts are still active.
ƒ Each 55µs, Timer 1 triggers an interrupt, thus wakening the microcontroller.
ƒ The task X() gets executed during approximately 21µs.
21µs Then
Then, the
microcontroller can get back to sleep for 34µs.

Wh t if the
What th task
t k X() llasts
t longer
l than
th expected?
t d?
Typical execution scheme
main() sleep sleep sleep sleep sleep sleep
ISR X() X() X() X() X()

21µs 34µs 21µs 34µs 21µs 34µs 31µs 24µs 21µs 34µs

INTERRUPT! INTERRUPT! INTERRUPT! INTERRUPT! INTERRUPT!

Timer 1 Timer 1 Timer 1 Timer 1 Timer 1 Timer 1 Timer 1

55µs 55µs 55µs 55µs 55µs

The timing remains unchanged:


X() still runs every 55 µs!

Bonus: the microcontroller sleeps about 60% of the time (in other
words, you can save a lot of energy, depending on the system).
Interrupts: some definitions
ƒ Interrupt Service Routine (ISR): simply another program function that gets
executed upon trigger of its associated interrupt.
ƒ Interrupt vector: a fixed address that contains the memory address of the ISR
ISR.
ƒ Interrupt flag: one bit in a register that indicates whether the interrupt has
been triggered or not.
ƒ Interrupt mask: one bit in a register that controls whether the interrupt can be
triggered or not
ƒ Non Maskable Interrupt
p ((NMI):
) an interrupt
p that is always
y active.
ƒ Asynchronous event: an event that could happen at any time (not necessarily
synchronized with the clock).
ƒ Time-triggered
Ti t i d interrupt:
i t t an interrupt
i t t that
th t is
i triggered
ti d by
b a timer
ti in
i a
periodic fashion.
ƒ Event-triggered interrupt: an interrupt that is triggered by an (external) event
(
(e.g., user input,
i A/D conversion,
i sensor measurement). )
Microphone on the real e-puck
ƒ First, you need a buffer to read the data from the microphone:
#define SAMPLELEN 1840 // for buffer allocation
static int values[SAMPLELEN]; // buffer and index for storing
static int valuesw; // index

ƒ Now, we will use an interrupt to sample periodically the measurements of the


microphone.
microphone
ƒ In our case, we want to achieve a sampling rate of 18 kHz (T = 55µs). Here we
set up the timer so that it triggers an interrupt each 55µs:

void InitTMR1(void) {
T1CON = 0;
T1CONbits.TCKPS = 0; // prescaler = 256
TMR1 = 0; // clear timer 1
PR1 = (MILLISEC/18.00); // 18KHz interrupt (T = 55 us)
IFS0bits.T1IF = 0; // clear interrupt flag
IEC0bits.T1IE = 1; // set interrupt enable bit
T1CONbits.TON = 1; // start Timer1
}
Microphone on the real e-puck
ƒ Now, we need to define an Interrupt Service Routine (ISR) that will be
executed each 55µs.
ƒ This function is very
y simple;
p ; it performs
p onlyy four operations:
p
ƒ First, it clears the interrupt flag so that the interrupt can be triggered again.
ƒ Second, it checks whether the buffer is full. If it is the case, it just returns
without doing anything.
anything
ƒ Third, it calls the function e_read_ad(int channel) for initiating a new
analog/digital conversion.
ƒ Finally, the new value is added to the buffer and the index is incremented.

void _ISRFAST _T1Interrupt(void) {


IFS0bits T1IF = 0;
IFS0bits.T1IF // 1.
1 clear interrupt flag

if (valuesw>(SAMPLELEN-1)) // 2. stop writing if buffer is full


{return;} // (will be reset in main loop)

values[valuesw++] = e_read_ad(MIC3); // 3. read one converted data


// 4. and add it to the
buffer
}
Microphone on the real e-puck
ƒ Finally, in the main loop, the code becomes very simple:
valuesw=0; // reset index so that _T1Interrupt
while (valuesw<SAMPLELEN) { // start to fill in the buffer
__asm__ volatile("nop"); // and wait until it is full
}

for (int i = 0; i<size; i++) {


printf("%d ",values[i]);
}
ƒ Note that the following piece of code allows one to include assembler
i t ti
instructions in
i C code.
d InI this
thi case, the
th instruction
i t ti is i nop, which
hi h means “no

operation”. It is useful to make the microcontroller “wait” for a while:
__asm__ volatile("nop");

ƒ Note that we use an active waiting loop, which is not really optimal from the
energy/scheduling point of view (see slides before).
ƒ A better practice would consist in putting the microcontroller in sleep mode
and using another software interrupt when the buffer is full to waken it and
print the values in the ISR.
Multiple I/O = Multiple tasks
Multiple I/O = Multiple tasks
Read
Sensing accelerometer
Read IR sensors Read camera

Crash Braitenberg
Process image
detection algorithm

Processing
5ms 10ms 300ms
Object recognition and detection

Task A
Task B
Turn LEDs Update wheel
Task C
Act ation
Actuation on motors
Dependency Maximal delay
Scheduling is the key!
Object recognition and detection

Braitenberg
algorithm Read camera

Read Crash Turn LEDs


Spare time
accelerometer detection on

1.1ms 0.7ms 0.8ms 2.4ms


5ms
Read IR sensors

Update wheel
Process image
motors
t

ƒ It is easy to carry out Task A (crash detection) in 5 ms.


ƒ Problem: there is only 2.4ms left for tasks B and C!
Solution: time-sharing
Read camera
Object recognition and detection

Braitenberg
algorithm

There is
Th i even some
spare time left!
Read Crash Turn LEDs
accelerometer detection on

1.1ms 0.7ms 0.8ms


5ms
Update wheel
motors
Read IR sensors Process image

ƒ Execute only subparts of the other tasks by preempting them!


ƒ Task B can be executed over 2 cycles of 5ms: split tasks into 2 subparts!
ƒ Task C can be executed over 60 cycles of 5ms: split tasks into 60 subparts!
Time-sharing
ƒ Time-sharing allows multiple tasks to be executed on a
microcontroller or processor in a pseudo-parallel manner, i.e.
they appear to run in parallel for the external observer even
though the execution is strictly sequential.
ƒ The pprinciple
p is to split
p the execution of each task into
multiple slices.
ƒ These slices can be re-organized in a different order that
complies
li with
ith the
th dependencies
d d i b between
t th
the ttasks
k in
i order
d
to optimize the use of the microcontroller.
ƒ There are two types of time-sharing:
time sharing:
ƒ Cooperative: the procedure/task itself must yield and give time to
other processes.
ƒ P
Preemptive:
ti a scheduler
h d l preempts the
h active
i procedure/task
d / k to give
i
time another process.
Time-sharing and memory
ƒ Time-sharing is a computation vs memory trade-off.
ƒ Indeed, in order to allow multiple tasks to run in an interlaced
manner, you needd to as much memory as they were actually
running in parallel.
ƒ Also
Also, you must take care of shared memory resources.
resources
Indeed, if multiple processes access the same memory
location, you need to coordinate them in order to avoid
unexpected
t d behaviors.
b h i
ƒ Assume that a process A reads a byte at memory address
0xF3A0 several times during its execution. However, it is
preempted during its execution in favor of process B, which
writes at memory address 0xF3A0. When process A becomes
active again
again, the byte at 0xF3A0
0 F3A0 has changed even though
process A assumes that it didn’t.
Scheduler
ƒ Preemptive time-sharing is very attractive, but it requires a smart
and efficient scheduler.
ƒ Upon preemption of the active process,
process the scheduler must decide
which process must be executed next and how much processing
time can be allocated to its execution before the next preemption.
ƒ To make these decisions, the scheduler must take into account
dependencies between the different processes, their respective
deadlines and priorities.
p
ƒ Generally, the scheduler is integrated into a more general software
framework, which serves an interface between hardware and user
applications called an operating system (OS)
applications, (OS).
ƒ Linux, Windows, MacOS X are typical operating systems for
desktop computers, but they are generally too demanding in
terms of computation and memory for embedded systems.
Operating system
ƒ An operating system (OS) is an interface between
hardware and user applications.
ƒ It is responsible for the management and
coordination of tasks and the sharing of the limited
resources of the computer system.
ƒ A ttypical
i l OS can be
b decomposed
d d into
i t the
th following
f ll i
entities:
ƒ Scheduler, which is responsible for the sharing of the
processing
i unit
it (microprocessor
( i or microcontroller)
i t ll )
ƒ Device drivers, which are low-level programs that
manage the various devices (sensors, actuators, secondary
memory storage devices
devices, etc.).
etc )
Most “OS” for
ƒ Memory management unit, which is responsible for the embedded systems
sharing of the memory (virtual memory). include these two
ƒ Optional: Graphical User Interface,
Interface File System,
System y
entities only!
Security, etc.
Device drivers
ƒ A device driver or software driver is a computer program allowing
higher-level computer programs to interact with a hardware device.
ƒ Device drivers pprovide an API that allows the user application
pp to access the
device in a simplified and standardized manner.
ƒ Reminder: an application programming interface (API) is a set of
functions,, procedures,
p , methods or classes that an operating
p g system,
y , libraryy
or service provides to support requests made by computer programs.
ƒ On the e-puck: no actual OS (no scheduler), but a standard library,
which can be considered as a device driver API API. The following features
are available: initialisation of basic hardware features, management of
proximity sensors, motor speed control, LEDs management, accelerometer
reading,
g, microphone
p sampling,
p g, sound emitting,g, image
g acquisition.
q
ƒ Example: the functions e_init_ad(void) and e_read_ad(int
channel) that are typical examples of functions that can be used by a
higher-level
higher level program to interact with a hardware device (the A/D
converter, and the microphone that is connected to it, in that case).
Conclusion
Take Home Messages
1. The complexity of a controller depends on the degree of
autonomy,y, mission to accomplish,
p , and environmental
conditions.
2. e-puck uses dsPIC as computational unit (programmable
in C), has a rich sensory set, actuation capabilities, and
bidirectional wireless and wired links
3
3. The hardware of an embedded device such an e-puck e puck
consists of a customized mechanical chassis and off-the-
shelf components
p (e.g.,
( g , dsPIC,, sensors,, other logic
g chips,
p,
connectors, motors) assembled on one or several printed
circuit boards (PCBs).
Take Home Messages
4. Programming embedded systems is all about resource
management, i.e. dealing with delays and time constraints
imposed by the environment and limitations of the hardware
(memory, computation, energy, communication bandwidth).
5 Energy
5. Energy, memory and computation are often very limited and
precious in real-time embedded system applications.
6. Often,, yyou need to make a trade-off between computation,
p ,
memory and communication using, for instance:
1. Time-sharing (for computation) and sleep mode (for energy)
2
2. C
Compression
i (for
(f memory))
7. Many other techniques exist, but the principle remains always
the same: find a trade-off between different resources in
order to achieve your objectives!
Additional Reading
ƒ For each of the concepts described in this course, do not hesitate
to use Google and Wikipedia for refining your understanding!
ƒ However, each of these concepts (scheduling, real-time
pprogramming,
g g, operating
p g systems)
y ) could be the topic
p of a
complete lecture, or even a whole course!
ƒ We want you to understand the general principles of these
diff
different concepts, andd why
h they
h might
i h be
b useful
f l to you as a
power user of embedded systems.
Additional Literature – Week 8
Manuals and technical documentation
• MPLAB C30 C Compiler User’s Guide
• dsPIC datasheet
• dsPIC30F Programmer’s
Programmer s Reference Manual
• e-puck website: http://www.e-puck.org/

You might also like