►
From YouTube: Jorge Aparicio Rivera - Rusty Robots
Description
Programming a self-balancing robot in Rust
Are we embedded yet? I'd say yes! In this talk I'll show you how I programmed a self-balancing robot from scratch. I'll cover IO abstractions, motion sensors, motor drivers, filters, control stuff, bare metal multitasking, logging, etc. And I'll explain how some of Rust features made development easier and made the program more correct.
Jorge (@japaric) has been part of the Rust community for over three years. Over that time he has contributed to the Rust compiler, standard library and other official Rust projects like Cargo. With his background in mechatronics engineering and the help of the vibrant embedded Rust sub-community he's working towards making Rust a great language and ecosystem for embedded development.
Rust devroom @ FOSDEM 2018
https://fosdem.org/2018/schedule/event/rusty_robots/
These talks have been recorded at FOSDEM (https://fosdem.org/)
This work is licensed under the Creative Commons Attribution 2.0 Belgium Licence.
To view a copy of this licence, visit http://creativecommons.org/licenses/by/2.0/be/deed.en
A
A
Okay,
so
this
is
the
robot,
and
this
is
the
front
view,
and
you
can
see
it's
a
wheel
robot
and
only
has
two
wheels
and
the
mass
of
white
on
the
top
is
the
electronics
that
will
control
it
and
there's
some
cortex
in
my
controller
in
there,
among
other
things,
and
this
the
side
view
you
can
see,
he
only
has
two
wheels,
no
extra
support
point
and
the
robot
is
clearly
unstable.
It
doesn't
matter
which
position
you
put
it
on.
A
It
will
always
fall
to
either
side,
and
this
is
similar
to
a
common
problem
in
control
theory,
which
is
the
inverted
pendulum
problem,
and
if
that
problem
we
have
an
inverted
pendulum
on
top
of
a
moving
car
which
you
can
move
using
this
force
F
now
the
pendulum
will
fall
due
to
gravity
and
to
compensate
that
falling
action.
What
you
have
to
do
is
if
the
pendulum
is
moving
to
a
lab,
then
you
also
have
to
move
the
car
to
a
left
to
compensate.
A
Okay,
so
we'll
need
to
find
that
tilt
angle,
and
for
that
we
have
an
accelerometer
on
the
robot
and,
as
the
name
implies
an
accelerometer
measures
proper
acceleration.
And
this
since
we're
using
as
the
MPU
9250.
Now,
how
do
I
get
the
tilt
angle
from
the
acceleration
and
accelerometers
even
when
they
are
non
moving?
They
always
sends
the
acceleration
of
the
gravity
and
on
the
picture
on
the
left,
you
see
that
the
sensor
is
horizontal
and
in
that
case
the
salaah
meter
is
going
to
indicate
that
the
acceleration
across
the
X
and
y-axis
are
zero.
A
But
across
the
CRC's
is
one
times
the
gravity
or
1g,
and
that's
going
to
be
a
fill
angle
of
zero
degrees
and
now
on
the
right.
You
see
that
I
have
tilde
essential
by
some
angle
and
it
had
case
they
really
across
the
y&z
axis
are
going
to
be
nonzero
and
if
you
do
some
trigonometry
there
you'll
find
out
that
the
angle
is
the
arctangent
of
the
ratio
of
the
Y
and
C
components
and
let's
see
how
that
works
out
in
practice.
A
This
is
data
collecting
from
the
accelerometer
and
one
is
horizontal
and
it's
not
moving
on
the
top.
You
see
the
acceleration
across
the
y
and
z
axis
and
the
Delta
is
noisy
and
at
the
bottom
you
see
the
our
tangent
formula
from
before
and
that's
going
to
be.
The
feel
angle
and
the
angle
is
around
2.9
degrees,
and
that
makes
sense,
since
the
sensory
isolation
valve
should
be
near
zero.
Now
what
happens
if
I
start
moving
the
SLO
meter
and
this
data
is
from
moving
the
thermometer
on
a
horizontal
table.
A
So
in
that
case
the
feel
angle
should
still
be
zero
because
I
know
tilt
in
the
sensor.
But
what
we
see
here
is
that,
once
you
compute
the
angle
using
the
formula
from
before
you
get
a
lot
of
oscillations,
and
this
is
clearly
wrong
and
the
problem
is
that
the
formula
from
before
was
assuming
that
the
only
acceleration
measured
by
the
sensor
passed
the
gravity
and
that's
not
going
to
be
the
case
as
soon
as
you
start
moving
the
sensor
now,
the
salami.
That
is
not
enough
to
get
us
telling
goals.
A
So
we
also
have
a
gyroscope
on
the
robot,
an
algebra
scope
measures,
the
angular
rate
or
the
speed
at
which
the
sensor
is
rotating,
and
this
is
perfect
because
with
this
we
can
measure
exactly
how
the
angle
is
changing
and
the
same
sense
of
from
before
has
both
an
accelerometer
and
a
gyroscope.
Again.
This
is
data
from
the
sensor
horizontally,
without
moving
at
the
top.
A
Once
the
sensor
has
been
calibrated
and
now
the
angular
rate
is
around
zero
and
once
you
compute
the
integral
at
the
bottom,
the
angle
is
also
around
zero,
which
is
the
correct
result.
You
want
now.
The
accelerometer
and
gyroscope
have
problems
on
their
own,
but
what
you
can
do
is
combine
both
measurements
using
a
technique
called
sensor.
A
Efficient
I
get
a
better
estimate
of
the
angle
and
turn
many
ways
to
do
sensor
vision,
but
a
Kalman
filter
is
appropriate
in
this
case
now
I'm
going
into
the
details
of
the
mat
behind
Kalman
filters,
but
as
you
said
that
they
are
not
actually
filters,
but
they
are
system
state
estimators
and
for
this
Kalman
filter
have
chosen
and
state
of
the
teal
angle
and
also
the
yellow
scope
bias.
And
here
we
see
a
simplified
interface
to
the
Canon.
A
Peter
has
omitted
some
tuning
parameters
from
here,
and
the
filter
have
to
start
with
some
initial
state,
which
is
the
angle
and
the
yellow
scope
bias,
and
then
every
time
we
have
a
new
measurement,
we
are
going
to
update
this
filter
and
what
the
filter
will
do
is
try
to
predict
a
nexus
state
using
his
previous
state
and
they
will
compare
that
to
the
measurements
from
the
yellow
scope
and
the
accelerometer,
and
you
start
information
to
get
a
better
estimate
of
the
angle,
and
this
is
Polly.
Kalman
filter
looks
like
in
action
again.
A
This
is
data
from
the
sensor
horizontal
without
moving
and
the
blue
dots
are
the
teal
angle
computed.
Only
using
accelerometer
data
and
the
Green
Line
is
the
Kalman
filter
and
what
said
the
same
thing
that
the
angle
is
around
2.9,
but
the
difference
is
that
the
Kalman
filter
has
much
less
noise
and
it
has
one
order
of
magnitude
less
noise.
A
Now
we
have
another
example
where
I
move
the
sensor
from
a
position
of
three
agrees
to
19,
and
the
blue
line
is
teal
angle
from
only
that
kilometer
and
Green
Line
is
the
Kalman
filter.
As
you
can
see
the
color
filter,
you
see
it
has
a
smooth
transition
from
0
to
90,
but
the
thermometer
has
oscillations
around
the
whole
transition,
while
were
using
the
Kalman
filter
here.
A
Ok,
now
we
have
the
angle
and
have
to
move
the
motors
to
be
able
to
stabilize
the
robot,
and
for
that
we
use
this
piece
of
electronics
called
H
bridge
and
this
module
has
to
a
bridge
and
we
can
use
that
to
control
the
two
motors
on
the
robot
and
with
h-bridge.
We
can
control
the
direction
of
the
motor
and
each
bridge
basically
use
four
switches
arranged.
As
you
see,
on
the
screen
and
on
the
left.
A
We
have
one
of
the
possible
states
of
the
H
bridge
and
in
that
state
the
power
supply
supplied
to
them
motor
and
I
will
apply
some
voltage
to
make
the
motor
move
and
and
the
state
on
the
right.
The
voltage
is
also
going
to
be
applied
to
the
motor,
but
with
reverse
polarity,
and
that
will
make
it
a
spin
in
the
other
direction.
So
it
has
four
switches
and
you
could
get
sixteen
different
possible
state
from
that.
But
in
practice
we
only
use
four
states.
A
A
We
will
stop
almost
immediately
and
with
this
bridge
you
can
also
control
the
speed
of
the
motor
which
we
are
going
to
need
in
this
robot,
and
we
can
do
that
using
this
technique
called
pulse
width,
modulation
and
the
main
idea
is
that,
instead
of
having
the
motor
connected
to
the
power
supply
the
whole
time,
we
are
going
to
connect
it
just
for
75%
of
the
time
say
and
you're
25%
we
are
going
to
leave
it
disconnected.
This
is
going
to
transfer
less
power
into
the
model.
A
We
should
make
it
a
spin
slower,
so
this
ratio
between
the
own
time
and
the
total
time
is
called
the
duty
cycle
and
it
can
go
from
zero
to
100%,
and
so
one
hundred
percent
will
make
the
motor
spin
at
full
speed
and
zero
will
make
it
stop.
Now
we
have
the
two
pieces,
we
have
the
angle
and
we
can
control
the
mother.
So
how
can
we
pick
a
duty
cycle
to
stabilize
the
robot?
We
can
use
this
PID
controller
and
there
in
this
diagram.
A
The
process
on
the
right
is
the
robot,
and
the
variable
Y
is
the
till
angle
measure
and
on
the
Left
we
have
this
variable
R,
which
is
the
set
point,
which
is
the
angle
we
want
the
trouble
to
be
at
so
if
we
pick
something
like
zero,
that
will
make
the
robot
stay
upright
and
the
difference
between
those
two
is
the
error
and
that
error
is
going
to
be
is
called
by
these
three
PID
gains
and
it's
going
to
turn
into
this
control.
Variable?
U,
which
is
the
duty
cycle?
A
A
We
get
a
stable
system,
the
robot
and
longer
Falls,
and
here
we
have
data
from
that
previous
video,
and
you
can
see
that
at
the
top
we
have
the
teal
angle
measure
and
the
blue
line,
and
the
Green
Line
is
the
set
point
which
shows
in
this
case
it
was
10
degrees
and
the
action
of
the
PID
controller
is
going
to
try
to
stabilize
the
teal
angle.
So
it
will
try
to
match
the
set
point
at
the
bottom.
You
can
see.
A
The
duty
cycle
shows
him
by
the
PID
controller
and
there
a
negative
value
means
that
the
motor
reverses
its
orientation.
But
that's
not
the
only
possible
outcome.
If
you
are
trying
to
guess
what
the
correct
KD
gains
are.
So
if
you're
in
chosen
correctly,
you
add
something
like
this:
an
unstable
system
and
what
you
got
there
is
oscillatory
behavior.
So,
instead
of
having
the
T
Lang
will
converge
to
the
set
point.
You
get
this
oscillation
around
the
set
point
and
well
that's
something
you
don't
want.
A
A
A
So
now,
let's
talk
about
how
rust
helped
build
this
kind
of
application,
and
in
this
diagram
you
see
the
microcontroller
in
the
center
and
the
other
components
are
the
external
components
to
which
the
my
controller
is
connected.
To
and
each
H
in
this
graph
is
one
of
the
my
controller
pins
and
the
direction
of
the
H
indicates
where
the
pin
is
configured
as
an
input
or
as
an
output,
and
the
label
indicates
what
the
functionality
of
that
pin
is,
and
the
bottom
line
here
is
that
you
want
to
configure
everything
correctly.
A
Otherwise,
your
system
will
not
work
and
you
will
have
a
hard
time
figuring
out
what
it's
not
working
and
Roskam
health
fear.
If
you
design
your
API
like
something
like
this
and
write
in
this
program,
we
are
going
to
set
up
a
serial
interface,
and
for
that
we
need
to
use
two
pins,
a
transmission
pin
TX
and
our
reception
pin
rx
now
and
the
first
line.
A
Now
the
frontline
is
going
to
change
the
pin,
pa9
into
is
going
to
put
it
into
alternate
push-pull
output
mode
and
that
being
we
are
going
to
use
for
the
TX,
pin
and
important.
To
note
here
is
the
type
of
the
TX
variable,
and
then
you
can
see
the
pin
name
pi9,
but
you
also
have
this
parameter
inside,
which
says
alternate
push-pull
and
that's
the
state
the
pin
is
in,
and
this
technique
of
putting
the
state
of
your
some
value
into
the
type
is
called
a
type
state
and
the
in
line
number
4.
A
A
Now,
this
constructor
is
written
in
such
a
way
that
if
you
haven't
configured
your
PIN
correctly
in
the
right
mode,
then
this
won't
compile
because
it
has
to
have
any
specific
type
to
be
passed
here.
And
that
means
that
you
cannot
do
the
configuration
incorrectly,
because
then
your
program
won't
compile,
and
another
thing
you
get
here
is
that,
for
example,
the
last
line
tries
to
change
the
mode
of
the
RX
pin
into
output
mode
and
that
will
break
the
seal
extraction,
because
the
cell
extraction
expects
that
pin
to
be
in
input
mode.
A
A
So
instead
of
writing
code
or
a
driver
that
lets
my
my
controller
interface
with
that
component
I
chose
to
write
the
driver
using
generic
programming
so
that
it
can
work
with
different
platforms,
and
the
key
here
with
generic
programming
are
traits
which
you
can
see,
and
this
spi
type
parameter
in
this
bound
by
these
two
traits
and
the
strains
are
interfaces
and
they
basically
said
you
can
construct
this
driver.
Is
you
pass
me
this
type
which
implements
this
SPI
interface?
A
And
that
means
that,
as
long
as
I
provide
a
type
that
implements
the
interface,
then
it
could
be
implemented
for
a
my
controller
or
for
a
raspberry
pi.
This
driver
doesn't
care
about
that
about
those
details,
so
this
driver
can
be
reused
across
different
devices
or
platforms,
and
now
so
the
community
is
putting
together.
This
embedded
help
right.
What
we
have
is
just
a
bunch
of
trades
which
represent
different
abstraction.
You
have
and
embedded
systems
which
are
sharing
a
phase,
spi
I,
to
see
bus
and
they
ultimate
goal
here
is
code
reuse.
A
Allow
then
out
this
year
and
the
communication
model
is
one
model.
Well,
was
really
shined
and
I'm
using
this
model
for
communicating
wirelessly
between
the
robot
and
my
laptop
or
my
phone,
and
this
model
steps
are
serial
interface
from
the
micron
Tori,
which
is
a
simplified
interface.
So
then
the
Macondo
doesn't
have
to
implement
the
Bluetooth
stack
now.
I
use
this
mainly
to
lock
data
from
the
robot.
So
then
I
can
analyze
that
later
on
and
this
model
is
limited
to
communication.
A
Speed
of
around
10
kilobytes
per
second
and
I
want
to
lock
data
really
fast,
so
I
have
two
shows
format
that
will.
Let
me
do
that,
and
I
chose
a
binary
form
and
just
directly
translate
all
the
types
into
binary
format.
But
in
my
application
you
have
to
write
any
binary
serialization
on
personality
instead,
I
simply
grab
this
biodegrade
from
Chris
dot,
IO
and
I
use
that
to
serialize
the
data
into
an
array,
and
now
this
works
and
I
can
send
data
in
binary
format
to
my
laptop.
A
But
there
is
a
problem,
because
this
is
a
wireless
link.
Data
might
be
dropped
if
the
robot
said
gets
too
far
away
so
to
sortal.
Prolene
I
can
add
friend
limiters
to
my
data
before
sending
that
and
for
that
I'm
going
to
use
this
cops
frame,
crate,
which
is
also
increased
load
I/o,
and
this
a
gorilla
had
a
friend
a
limiter
which
is
usually
zero
and
then
translates
the
rest
of
the
data.
A
So
it
doesn't
have
any
zero
in
there
and
it
what
provides
a
way
to
encode
and
decode
the
frame
and
once
I
had
that,
then
my
data
was
properly
friendly,
limited,
but
then
I
started
wondering.
Could
it
be
that
I
lose
some
weight
right
and
I
still
get
a
valid
frame
on
the
laptop
and
I
will
still
get
a
young
date
out
of
that
so
I
checksum
to
my
data
to
verify
that
the
frame
is
actually
what
I
wanted
to
send
and
again.
A
I
didn't
implement
that
in
my
application,
I
simply
grab
a
checksum
Crichton
press
dot
IO
in
this
case
the
CRC
16,
and
here
you
can
see
the
full
code.
I
sterilize
my
data
and
compute
the
checksum
append
that
and
then
turn
that
into
a
cop's
print
and
put
on
the
wire
and
one
of
the
last
parts
is
concurrency.
So
I
have
to
do
multitasking
on
the
my
controller
and
I.
A
Don't
have
to
do
this
two
tasks
and
for
that
I
use
this
real
time
for
the
masses
or
RTFM
framework,
and
it
lets
me
do
a
task
on
top
of
inner
handlers.
So
it's
basically
a
harbor
base
scheduler.
So
it
is
really
fast
and
efficient.
But
since
this
was
I
have
to
worry
about
data
races,
so
I
have
this
two
tasks.
One
was
periodic
where
I
read
the
sensors
update.
A
Variables
are
troublesome
one
because
they,
you
might
run
into
that
arises,
but
I
think
a
major
problem
from
my
point
of
view
is
that
they
make
the
code
and
not
read,
because
then
anything
can
modify
the
variables.
So
you
don't
know
who
has
access
to
the
variable,
but
with
this
framework
we
have
this
declare
a
tip-up
macro,
where
you
define
all
your
resources,
which
are
nothing
else
that
static
variables.
And
then
you
declare
your
task
and
you
assign
the
resources
to
the
task.
A
If
you
have
sharing
between
a
resource
is
shared
between
two
tasks
and
the
frame
will
take
care
of
ensuring
that
the
access
is
free
of
that
raises
and,
for
example,
they
are
staffed
at
the
bottom
to
access
the
PID
resources
share.
It
has
to
use
a
lock
to
achieve
data,
raise
freedom,
okay,
some
other
random
stuff.
The
CPU
uses
of
the
migrant
dollar
was
around
21
percent.
The
CPU
was
running,
a
64
may
occurs
and
had
no
FPU
and
the
control
loop
was
running
around
500
times
per
second
binary
size.
A
My
application
was
around
what
four
hundred
lines
of
code
excluding
the
code
from
the
dependencies.
Everything
that
ended
in
the
binary
came
from
our
source
code
and
the
binary
size
was
around
eight
point:
five
kilobytes
in
flash
an
actor
like
two
kilobytes
of
that
are
due
to
software
emulation
of
flowed
aromatic
because
I
don't
have
an
FPU
Ram
was
140,
bytes
and
I.
Didn't
use
any
dynamic
memory
allocation
the
button
you
can
see
they,
the
biggest
symbols
and
a
mountain.
You
will
find
this
software
emulation
of
ITP
floats.
A
Finally,
this
is
the
dependency
graph
of
the
project.
It
has
around
20
dependencies
excluding
build
dependencies.
So
there's
a
lot
of
code
reuse
in
there.
One
thing
I
found
scary,
is
that
most
of
those
crates
have
been
written
by
me,
except
for
like
three
or
four.
But
if
you
were
writing
this,
then
you
have
to
do
all
the
work
right
in
the
dependencies.
A
Okay.
In
conclusion,
ross
is
small
enough,
so
he
can
fit
in
a
micron.
Juror
is
also
perform
enough
that
you
can
implement
this
time-sensitive
control
system
on
a
resource-constrained
device
is
also
memory
safe.
You
can
do
multitasking
without
having
to
care
about
data
races
or
whatever
that
it
also
lets.
You
write
more
correct
code.
We
saw
in
the
pink
configuration
you
cannot
get
it
wrong
with
the
api.
You
can
also
easily
use
the
particle
which
we
use
a
lot
in
the
communication
module
and
it's
also
good
for
code.
A
A
So
what
is
already
a
costume?
Oh,
yes,
the
question
was:
how
was
it
to
cross-compiled
to
that
target?
So
I
think,
is
that
the
rest
compiler
is
already
a
cross
compiler
by
default.
So
I
didn't
need
to
do
anything.
Special
I
could
really
generate
machine
code
for
the
context.
Mike
Rinder,
the
only
external
dude
told
that
I
needed
was
a
linker,
because
Rossi
doesn't
include
a
linker
inside,
so
I
use,
LD,
unknown,
ABI
LD,
and
then
there
was
the
only
external
dependency
I
had.
A
A
Okay,
the
question
is
so
it
was
using
a
cortex
in
my
condo
how
hard
will
be
to
support
all
the
architects.
It
also
all
the
other,
my
controllers,
right:
okay,
okay,
only
about
the
cortex,
my
controller
and
so
to
get
a
more
device
support.
We
have
a
tool
called
SVD,
two
rods
which
so
benders
give
us
this
description
of
all
the
register.
In
a
my
controller
in
this
SVD
format,
which
is
a
finished,
an
XML
file,
and
we
can
translate
that
into
rust,
coated
levels
use
all
the
registers.
A
On
the
my
contrary,
so
that
gets
like
ninety
percent
of
the
work
done
and
if
you
have
the
SVD
file
for
American
product
and
basically
you
can
already
do
io
and
use
the
registers,
and
on
top
of
that,
you
will
want
to
build
something.
A
slightly
higher
level
because
manipulating
the
register
can
be
error-prone,
and
for
that
we
have
this
embedded
halt
rates
and
if
you
implement
a
halt,
I
uses
that
interface.
A
Then
it's
like
a
10
percent
of
the
job
left
and
once
you
do
that,
then
you
get
access
to
these
generic
drivers
right
now.
People
are
mainly
using
stm32.
My
controllers,
I,
have
seen
some
people
using
like
an
XP
LPC
and
a
bit
of
sound
from
a
PR,
and
but
the
boards
that
have
most
support
are
the
blue
pill,
which
is
the
one
here
and
a
few
of
the
discoveries
is.