Fall 2011
CSCI P545 –
Embedded & Real-Time Systems
What's New – Look here regularly for postings
|
|
Dec 16 2011
|
| Comments on projects have been sent to all participants. Grades are
included. Official grades have been posted and will be available before
7:00am tomorrow according to the Registrar.
|
| Special recognition:
- Shenshen Han for
- Best Lab Project Report
[PDF]
- Individual project in drive-by-voice
[PDF] (see the
demo [HTM])
- Hasan Kurban, Doga Tuncay and Kurt Weisman, the only
group to demonstrate avoidance using the SICK LMS100 laser range-finder
[PNG] (They
note in their report that only three cones had to die in order to complete
this test)
- Shiva Sinhya and Ben Zaitlen
- Best Lab Project Report
[PDF]
- Individual project in ERTS vision
[PDF]
|
|
|
Course:
|
P545 Embedded & Real-Time Systems
B490 Experiments in Autonomous Robotics (3 cr.)
The term embedded system refers to software
executing in a dedicated setting. Some examples are: hand-held devices, cell phones,
consumer electronics, robots, automotive systems, avionics and smart cards, to name just
a few. It has been said that, two withing three digits of accuracy, 100% of computing is
embedded. This is a project-oriented course in which classroom topics
are explored through in-depth experiences in a substantial laboratory project.
|
Lecture:
Lab: Engineering:
|
Steve Johnson
(sjohnson). Office hours to be announced.
Caleb Hess
TBD
|
Meetings:
|
Lecture: | 9:30-10:45 MW LH035
| Lab: | 2:30-5:30 F P545 Test Field, conditions permitting, or LH035
|
|
Description:
|
P545 Embedded and Real-Time Systems (3 cr.)
P:
Any 400-level ``systems'' course (middle digit 3 or 4).
Design and implementation of purpose-specific, locally distributed
software systems. Models and methods for time-critical applications.
Real-time operating systems. Testing, validation, and verification.
Safety-critical design. Related topics, such as resiliency,
synchronization, sensor fusion, etc. Lecture and laboratory.
NOTE:
Students with deficiencies but having compensatory special interests
(e.g. instrumentation science, robotics, cognitive science, multimedia, etc.)
are encouraged to consult with the instructor about approval to enroll.
|
Laboratory:
|
ERTS is a computer controlled golf car.
In the first half of the course, students do a cumulative sequence of
assignments learning basic GPS navigation and obstacle avoidance.
In the latter half, projects are based individual interests and backgrounds.
The ERTS Test Field is located on the
parking lot between Assembly Hall and the Tennis Pavilion.
|
|
Please Note:
Embedded system design requires a broad background, encompassing both
system engineering and "domain expertise." This course is designed
to accomodate students with varied interests and goals.
See Background Requirements below. However,
the higher aim of the course laboratory is to develop a configurable
platform for collaborative research in systems, sensor networks
(especially vision), and congnitive science (especially machine learning and
human-robot interaction).
There are other participation options, including for undergraduates.
Contact the instructor if you are interested
in participating on an individual basis.
The term embedded system refers to purpose-specific software
executing in a dedicated setting. Some examples are: cellular telephony,
network routing devices, consumer electronics, robots, digital avionics,
automotive systems, and ``smart'' cards, to name a few.
This is an advanced, project-oriented course in which classroom topics
are explored through in-depth experiences in a substantial laboratory project.
Embedded systems are ubiquitous in modern
society. Their defining characteristics are distinctive in many
aspects, and consquently, their mathematical models, design methods,
implementation techniques, operating systems, performance analysis,
and computer-aided design tools differ substantially from those
for to other classes of systems. Furthermore, underlying
technologies are evolving rapidly. The perspective offered in lecture
is augmented by a substantial, cumulative laboratory project,
which provides the necessary experience to pursue projects
and research entailing embedded-system use or design.
NOTE:
Students with deficiencies but having compensatory special interests
(e.g. instrumentation science, robotics, cognitive science, multimedia, etc.)
are encouraged to consult with the instructor about approval to enroll.
The course assumes a basic fluency in ``systems'' concepts/terminology
and senior-level programming competency. Additional background in
diverse areas such as networks, distributed computing, hardware, etc.,
is desirable but not required.
Much of the programming involves interaction with the underlying
operating system through system calls. Exposure comparable to
that of the Operating Systems (P436) is adequate preparation.
Specific OS facilities used include: sockets, signals,
time, timers, and a few others.
Embedded systems are typically made up of both software and hardware
components. This course focuses on software aspects.
However, if a sufficient number of hardware students are enrolled,
opportunities will be created to work in that realm, most likely
using FPGA and micro-controller technologies, as taught in P442.
There is no required textbook. Lecture notes and additional readings are
distributed electronically through this web page. Many of the lectures draw from
Kopetz's textbook, Real-Time Systems: Design Principles for Distributed Embedded Applications. (See below) Students may wish to acquire an advanced book on
system-level programming in Unix and/or an introductory Python programming manual.
-
Hermann Kopetz. (Recommended but not required)
Real-Time Systems: Design Principles for Distributed Embedded Applications.
Kluwer Academic Publishers, 1997. Strong
orientation toward safety-critical application, sychronous methods and
resiliency.
-
Wayne Wolf. High-Performance Embedded Computing: Architectures, Algorithms, and Applications. Morgan-Kauffman Publishers, 2006. A textbook focusing on embedded architecutes and technologies.
-
Alan Burns and Andy Wellings.
Real-Time Systems and Programming Languages
Addison-Wesley, 2001 (3rd ed.). Numerous programming examples.
-
Jane W.~S.~Liu.
Real-Time Systems.
Prentice-Hall, 2000.
A good but dated general textbook.
-
Qing Li with Caroline Yao.
Real-Time Concepts for Embedded Systems.
CMP Books, 2003.
A good but dated general textbook.
-
W. Richard Stevens and Stephen A. Rago.
Advance Programming in the UNIX® Environment (2nd ed.),
Addison-Wesley, 2005.
Architectures, Algorithms, and Applications. Morgan-Kauffman Publishers.
A good reference for Linux/Unix programming.
Tentative. Based on 40 aggregate lecture hours, based on 32 75-minute lectures
|
Architectures and Applications [1].
Digital control; "smart" electronics; sensor arrays; multimedia;
networking components; instrumentation; heterogeneous systems;
system-on-chip. Networks: ad hoc, common-carrier, hierarchical etc.
|
|
Terminology and Tradeoffs [2].
Reactive systems, event models; periodicity; throughput, latency, jitter,
slack; polling and sampling; modes and configurability; resilience;
hard-time and soft-time constraints. Worst-case and expected-case
analysis.
|
|
Tools and technologies [6]
Tools, design flows, libraries and packages, instrumentation,
documentation.
|
|
Time [3].
Physical and logical; resolution, precision, accuracy;
global and distributed synchronization. Clock synchronization
algorithms, agreement protocols.
|
|
Resiliency [3]
Faults, errors and failures; failure rates, transient failure; fault models;
fault containment; fault tolerance and agreement; recovery.
|
|
Communication [4]
Time division, carrier sense, collision-detect, etc. OSA model.
Representative standards (e.g. IP, FlexRay, CAN, WiFi, ad hoc).
Buffer network analysis.
|
|
Real-Time Operating Systems [6]
Threads, tasks, processes periodicity. Scheduling
parameters, static and dynamic heuristics; Thread integration, priorities
and preemption. Models and instances of memory/file management.
|
|
Methods [2]
Process-oriented design; synchronous and asynchronous abstractions;
message based, image based, data-flow, etc. Design flow, simulation.
Requirements, specification, implementation.
|
|
Testing. [3]
Unit, component, integration testing;
Testing frameworks, simulation.
Instrumentation and measurement;
Validation and verification;
Formal analysis: models, tools.
Safety aspects: classification, certification, documentation.
|
|
Sensors [4].
Statistical models, resolution, filters;
feature synthesis and fusion.
|
|
Components [4]
Device handling, point-to-point protocols (e.g. USB, Firewire);
Platform computers, microcontrollers, FPGAs and software cores;
Codesign, incorporating hardware, configurability and reconfigurability.
|
The primary programming language used in this course is
Python running under
Linux. Python is
a scripting language, increasingly popular for rapid prototyping.
Prior knowledge of Python is not assumed, but it is expected that
participants have enough programming experience to learn it as the
progress.
Later in the course, the choice of language and system is left to the
student. At higher levels, one goal is to "mount" existing software
systems for experimentation in ERTS. For students who are
interested in exploring embedded systems at lower implementation levels,
knowledge of C, and familiarity with Linux system calls is needed.
For students interested in real-time operating system (RTOS) aspects,
copies of the QNX RTOS are available.
The course project includes a substantial, documented
design effort. The class will uses the
Doxygen
documentation generator for this purpose.
The standard course laboratory is a full-semester, whole-class project
involving specification, design, implementation, and testing
of a real embedded system.
Participants work in teams of 3 to 5 people; and every effort
is made to assure that each team, in aggregate, has the necessary
skills to complete the project successfully.
The primary components in evaluating
projects are (1) field testing for functionality and (2)
documentation the work, which may include oral presentations.
The laboratory platform is a golf car modified for computer control.
Previous classes have developed basic solutions for:
-
autonomous navigation system using the Global Positioning System
(GPS) to follow a pre-determined course, and
-
obstacle detection using a short-range laser range-finding sensor.
Each successive class will refine and enhance existing capabilities.
The goals in the coming semester include:
- real-time obstacle avoidance
- integration of a vision system
- experimental prototyping for other researchers.
Initially, the class is given a software framework
for controlling steering, acceleration and breaking, as well
as sensors for GPS, proximate object detection, and rudimentary vision.
Classroom lectures explain and explore the
implementation of the framework as student groups develop solutions to
the navigation problems in a cumulative series of lab assignments,
such as:
-
Lab bench exercises dealing with time measurement
-
Evaluation of prior GPS Navigation projects
-
Empirical characterization vehicle dynamics
-
Path planing, tested in simulation
-
Field testing for refined path planning and obstacle detection.
to continue throughout the rest of the semester.
-
Integrating external sensor input
-
Sensor fusion, tactical path planning
-
Public demonstration of results
As participants develop and test their implementations of higher functionality,
they are contributing to the on-going design and enhancement of the research
platform by reporting on its empirical performance
in comparison to design assumptions on which their software
development is based.
Most, if not all, of your grade in this course is based on two projects: The Lab Project that all
participants are assigned to do and an Individual Project that participants propose. There may be
occasional in-class quizzes, but I do not plan to give any major examinations (unless you ask me to).
Projects are evaluated as follows, in order of importance
- Demonstration of the project in a live field test. A project is not considered unless it has been
demonstrated. In particular, projects done only in simulation are not evaluated. Conditions permitting
we will hold public field trials of the Lab Project at the end of the semester.
- A written report. A great deal of weight is given to the quality of the report. If you cannot present
the work clearly in writing, the results are of little meaning.
- A presentation. It is of substantial help in understanding the written report if you make a clear
presentation of the most important aspects.
- System documentation. A good project is one that can easily be taken up and advanced by another
student.
Grades reflect the quality of your participation in relation to current and past classes. From the
instructors perspective, a grade of A or A- says that you have excelled in the subject and shown
the aptitudes necessary to specialized in the area, if you choose to do so. A grade of B+, B or
B- says that you have completed the course satisfactorily, but the instructor has reservations about whether
you should pursue studies further in this area. If you want to continue in the area you should consult with the
instructor to discuss these reservations. A grade of C+ or C says that you have completed the course for credit, but (in the instructor's opinion) have defficiencies in aptitude or background that would
significantly impair you ability to pursue further study in this area.
Please review: