CyVS: Lab 1 - me.utexas.edulongoria/CyVS/Lab1/Lab1_sbRIO_familiarity_v3.… · CyVS: Lab 1 Begin:...

ME 379M/397 – Prof. R.G. LongoriaCyber Vehicle Systems

Department of Mechanical EngineeringThe University of Texas at Austin

CyVS: Lab 1

Begin: Monday, Feb. 9, 2015 (v3)

Updated with results on 2/20/15



The goal of this first lab is to gain familiarity with the sbRIO

platform that is used as a controller on the DaNI robotic vehicle.

ethernet

connection

Real-time

processorFPGA chip

Analog IO

Digital IO



UserGuide_sbRIO_96xx.pdf

ethernet

connection

See p. 22 for information on LEDs;

for example:

P4 connector

(used by DaNI)

P2 connectorP3 connector

P5 connector



Ultimately, we want to study the code that is used to control the

motors and understand how the drive signals are sent to the motor

controller used on the DaNI and also how the wheel speed is

measured using the built-in encoders. We’ll try to get there in 3

exercises.

Part 1 (Week 1):

• Exercise 1: Get comfortable with LabVIEW and using the real-

time platform, as well as basic FPGA programming.

• Exercise 2: Learn how to use the analog in and analog out,

measure accelerometer signals and drive an analog meter, more

practice with communications to the FPGA from RT platform

Part 2 (Week 2):

• Exercise 3: Study the Custom FPGA code used on the DaNI

and reverse engineer the code to understand motor drives and

encoder sensing. Relate results from HW #1 with Lab #1.



This is actually DaNI 1.0

NOTE that the DaNI only uses

digital I/O from P4 connector



Exercise 1: Building a simple real-time

program on sbRIO

We’re going to build the classic ‘blinking

LED’ example using sbRIO.

You will need the following: Windows machine with requisite

LabVIEW software, cross-over cable, DaNI robot with breadboard,

at least 2 male-female jumper wires, one LED



First you need to identify the digital IO on the sbRIO you will use –

refer to the User’s Guide.

Connect an LED

across an available

port and D GND

For example, you

can use the P5

connector indicated

here. The P4 is

used by DaNI.

P

4



NOTE: It’s important to be aware of the digital I/O and analog I/O limitations. This

information is provided in the User’s Guide and should be referenced in future applications.

For this lab, the 3.3V output on the digital I/O should not have any problems driving the LED.

The manual also has information

on how to use the analog I/O in

differential pairs:



Getting Started:

1. The DaNI robot should already be on the benchtop, and it is

preferred that it be “up on blocks” so that if any drive signals are

sent to the motors there will not be any induced motion.

Leave the Motor switch in OFF position for this lab.

2. An ethernet cable should be attached between the host computer

and the ethernet connector on the sbRIO. This is a cross-over

cable that allows communications between these two systems.

3. You should open up NI MAX so you can check connection to the

remote system. Make note of the IP address.



Build the application from scratch – later we may use the robotics

wizard, but for now you will build your own program, including

compiling a small FPGA program. Press “Create Project” and then

select “LabVIEW FPGA Project templates”

The wizard will give you options (to

left)…select “Single-Board RIO Embedded

System”, then “Discover existing system”. It

will look for connected boards and you

should see the DaNI system. Hit Next …



Here is what you might see next:

Go ahead and hit “Discover”. Then you’ll see:

Press Finish.



Begin by building an FPGA program.

Expand the “Chassis (sbRIO-963x0) and you will see the FPGA

Target (RIO0, sbRIO-963x). For DaNI 2.0, the ‘x’ is a ‘2’.

Right click on the FPGA target and create a new VI. A blank VI will

be created. On the block diagram, develop a VI to control the digital

I/O to turn on and off. Here is one way to do this:

The stop terminal is for a control and the iterations terminal is an indicator. These should

appear on the front panel. It is assumed you know how to build this type of block

diagram in LabVIEW. If not, you need to complete the introductory online tutorials.

Note: this uses Port 7 on P5 connector, I/O 2.



You should be using the pop-up menus to access the FPGA I/O items.

Here you’ll need the I/O Node:

Go to the Timing sub-menu to grab the “Wait” vi. Set it to use

msec and then create a constant as shown.

Once you place an

I/O Node on your VI,

right-clicking on it

will show you want is

available on your

FPGA target.

In this example, the

DIO2 on Port 5 has

been chosen.



Here is the end result. Save this VI, and it should appear under the

FPGA Target in your project.



Now, let’s hook up the LED. We used DIO2 on Port 7, which is on

P5 connector. Use jumper wires (M/F) to connect from DGND (pin

1 on P5) and DIO5 (pin 7 on P5) to the breadboard that is mounted

on the DaNI’s top plate, as shown below.



Now run this VI from the front panel. If this FPGA VI has not been

previously compiled, or if changes have been made, you will be

asked to select a compile server:

For this simple program, it will take about 5-7 min to compile locally, depending

on your host computer. Selecting the local compile server, first you will see some

work on generating intermediate files, then the Compilation Status window will

open up. Let it run. You may get an initially busy message, just ignore and it will

usually get started. While you are waiting, see the next slide.



What you are doing now is running the FPGA interactively. See below from context help.



After the compilation is completed, and if there are no errors, the

program should start running and you’ll see the LED flashing.

You will feel really good.

The next step is to build a real-time VI that runs on the sbRIO that

can call this FPGA VI.

Read over the next slide which has an excerpt from the LabVIEW

context help.

You can let the LED blink…



OK, so now you build this RT VI that uses the FPGA VI.

Let’s look at the project window first.



Note how the

dio_on_off_FPGA_1.vi just built

sits under the FPGA Target.

To create a VI on the RT host,

right-click on the higher-level

(here PVDaNI) and select New

VI from the drop-down menu.

You’ll see an Untitled VI created

in the project browser that is at

the same level as the FPGA

Target.

Build the block diagram shown

on the following slide.



This real-time (RT) VI calls the FPGA target and runs the program

we just created. After a certain number of iterations are counted, the

program stops and then closes and resets the FPGA target.

This is a control to

set how many times

you want to blink

Next slide explains some

elements of this VI.



On the block diagram, begin by placing four VIs from those indicated as shown:



Right-click on the FPGA VI Reference VI to configure, and subsequent windows

allow you to select the FPGA Target VI just created.

Select the FPGA

VI you created,

and hit OK.

Select ‘VI’

then browse

your project

(to right) to

select the

FPGA VI.



After you configure the FPGA target to reference and wire the reference connections

between the FPGA interface VIs, you can then left click each Read/Write VI to select

which variable you want to read or write.

Set the iterations variable on the front panel, then Run.

You should now be able to blink the LED a given number of times.

This is the end of Exercise 1 for Lab 1.

Reference wire

FPGA

Read/Write



Reporting on Lab 1/Exercise 1.

1.Summarize you completion of this exercise by

submitting an electronic report with screen

captures of your VIs.

2.Summarize any problems you had with the

tutorial. How long did it take? What could

have improved the tutorial.

3.Report success in getting it to work.

This exercise is about ‘doing’, so a one page

summary is sufficient.



Exercise 2: add an AI, maybe some

AO on the FPGA program

The baseline DaNI platform only uses digital I/O on the sbRIO 9632.

We may later want to gather data from analog sensors or send out

analog drive signals.

In this second exercise, you’ll experiment with both the analog in

(AI) and analog out (AO) channels.

You will measure signals from an accelerometer, and use that signal

to drive an analog dial gauge.



Those of you who have taken my DSC lab know I really like

these little analog meters and accelerometers. Why not spread

the love here.



The analog channels on the sbRIO 9632 are on the J7 connector.

All the grounds are

connected together,

however there are

some cases where

you should be

careful since noise

from a load on an

AO channel could

disrupt some of the

timing. See the

user’s guide.



For this exercise, you will connect a Crossbow LP accelerometer to

one of the analog channels.

You may be provided with an accelerometer that can measure

acceleration in only one direction or in 3 (i.e., X, Y, Z). Either way,

pin 1 on the accelerometer connector is +5V, pin 2 is GND, and the

next three pins are for the three acceleration signal outputs. Use only

pin 3 if it is a single-axis accelerometer.

Pin 1 in indicated by a mark on the connector as shown below.



You’ll need to use jumper wires to connect the accelerometer to the

analog I/O channels.

Use the +5 V DC output from one of the digital I/O connectors as the

power input to the accelerometer. Connect the accelerometer ground

to D GND.

Then, choose the accelerometer output and connect this to one of the

analog input channels.

Be aware that these accelerometers will only provide an output

between 0 and 5 V. Also, these are DC acclerometers, meaning they

can measure constant acceleration like gravity. So if you align the

axis you are measuring with gravity, it will show a constant change in

voltage. For these accelerometers, that will be about 0.5 V for 1 g.



tri-axial accelerometer

These accelerometers have a ‘sensitivity’ of

about 0.5 V/g



0g =

This is the value that is read when there is

zero g applied to each axis. The values are

often given, for example, below.

Because these accelerometers can

read up to 4 g, they have an

output span of +/- 2V about the

zero g value of ~2.5 V.

Each axis also has a ‘zero-G’ voltage



OK, so if you lay the accelerometer on the table and you read

the output from the X axis, which would NOT be exposed to

gravity, then it has zero G applied and the reading should be

about 2.5 V.

If you now shake it with your hand in the plane of the table, you

should get a signal that varies about 2.5 V.

This is all you will do with the accelerometer.

Of course, you need to measure that output and then use it to

drive an analog output channel.

NOTE: Make sure to design your VI so that when you stop it the

AO goes to zero. We don’t want to leave the ‘meter’ at a high

value (e.g., ~2.5 V for zero g).



Here is what you need to assemble for exercise 2. Note

that when you hook up the analog voltmeter, you will

need to use a series resistor in the circuit or you will over-

range the meter. This series resistor will be provided.



Sample time – I used a

timed loop on the RT VI

to set how often I sample

the FPGA

For fun, I put the analog

measurement on a meter

on the front panel,

mimicking the real

one…

Next slide shows ‘most’ of the RT VI. Don’t have to do it this way.

Here is what the front panel on my RT level VI

looks like.



Here is most of the block diagram. You’ll need to figure out the FPGA level.



Reporting on Lab 1/Exercise 2.

Because there is a wide range of experience in this class, I expect some may

easily complete Ex 2 while others may struggle. Do it in steps! First get the

acceleration signal working. Then try the analog out for driving the meter.

1. Sketch out your final configuration and take a photo.

2. Provide descriptions of both your FPGA and RT VIs.

3. Summarize your relative success. Ultimately, the

point is to gain comfort/familiarity with both digital

and analog I/O with the sbRIO.



Exercise 3: Sensing and controlling

motor/wheel speedHere we’ll now explore the custom DaNI code to

understand how we can use the FPGA to read encoders

and to guide development of a PWM drive.

For sure we will study the open-loop case.

Depending on time, we may also look at closed-loop

control, studying how PID loops can be implemented on

the sbRIO.



In this last exercise, we will build a PWM drive circuit by studying

how this was done by NI for the DaNI robot.

The point is to drive the DaNI with open loop levels of PWM

modulation while also measuring the Tetrix motor output shaft speed

(in rad/sec) using the integrated encoder.

We will also compare results with our mathematical modeling and

simulation form HW #1 and determine how to best model the

drivetrain. This should help when we study implementing feedback

control for motor speed and ultimately for cruise control of this small

robotic vehicle.



Begin by going into the original examples files in the LabVIEW installation, and copy the

entire Starter Kit 2.0 Custom FPGA folder. Here is the folder address:

E:\National Instruments\LabVIEW 2013\examples\robotics\Starter Kit 2.0 Custom FPGA

Make a copy of the entire folder in your own

working folder.

Open the project. Don’t bother connecting to

your DaNI system since we won’t compile

this code at this time. We will harvest some of

the example code for use in this exercise.

Open the FPGA Main VI indicated to the

right.



We’re going to extract code from the block diagram of this custom FPGA code…



Create a new project on your DaNI sbRIO (FPGA project), then create a

new VI to start building an encoder and motor drive FPGA code for this lab

exercise. Start by copying and pasting into your FPGA VI block diagram the

two-channel encoder loop from the Starter Kit 2.0 Custom FPGA VI. Note that the

output is ppi,

pulses per

interval, and the

time unit is

‘ticks’.

1 ‘tick’ is one

‘cycle’ on the

FPGA, which

runs at 40 MHz.

Upper limit on

interval is

640000 ticks =

16 msec.

Let’s look at

what is in this

loop.



Side bar: If you’ve never used local and global variables in LabVIEW before, it

is worth looking at this basic tutorial on the NI website:

http://www.ni.com/tutorial/7585/en/

global

local

What’s the difference? See the tutorial.



The next slide decomposes the Encoder Loop.

Note that it can be used to monitor two

encoders, and you could extend to more.

The output is in pulses/interval (or cycle) not

speed (e.g., rad/sec).



Encoders on these

motors are

mounted on the

wheel shaft.

Be aware that the motor shaft is turning at GR

times the wheel shaft, where GR = 20 for these

motors.

Gear-head

Encoder

sbRIO DIO



If you look at the Project Browser, some of these functions

appear under ‘Dependencies’, and get loaded as part of a

library:



This is an excerpt from LV help

on the Feedback Node.



Now, need to drive the motors to test out the encoders.

Driving the motors with PWM. Below is the Motor Drive Control Loop on the

Custom FPGA VI for the Starter Kit 2.0 (DaNI)

First, note that this is a multi-channel drive. The For Loop will run ‘N’ times,

where N is the length of the array formed by the two motor ppi values conveyed

via these global variables.

Integer array, N =2



Side bar: Here is an example of how a For Loop takes

on ‘N’ from the input array size.



Before we add the motor drive loop to the VI, note that the part in the red box below is all

you need to drive the motors. You need to specify the pulse width between 1000 and 2000

usec, with 1500 usec corresponding to ‘stop’. See next couple of slides for particulars on the

motor controller.

You also need the code here which takes ppi from the Encoder loop and converts to

rad/sec. Let’s look at what is in the ‘Convert Velocity’ subVI.



First, here are some

particulars on the Sabertooth

motor controller.



The dip

switches are set

for this mode.

NOTE: These are

the dip switches

on the Sabertooth

motor controller

used on the DanI,

NOT on the

sbRIO.

This is just FYI –

DO NOT change

any of the dip

switch settings.



rad

pulses rev

secpulsestick

tickrev

2

1

cyc

cycp

N

TN

π

ω

⋅ ⋅ ≅ ⋅

from encoder loop, ppi

from encoder spec, 400 ppr

from FPGA spec, 40 MHz

cyc

p

cyc

N

N

T

=

=

=

6

1

40 10 ticks/seccyc

T =⋅Note, using ‘interval’ or ‘tick’ synonymously.

Now, the Constant Velocity subVI gives you angular velocity based

on the encoder ppi measurement. Study this basic conversion, and

feel comfortable you could have built this yourself.



Note that the PID controller (which we won’t use here) takes the converted

velocity (in rad/sec) and ‘Normalizes’ before sending it into the FPGA PID subVI.

We may look at this later, but since we won’t use it let’s not worry about that right

now.

Bottom line is you need to give an open loop command to the I32 conversion.

Remember, these values vary from [-500,500] usec.

Pulse width (usec)



FYI: Here is what the PWM VI looks like:

This type of code using basic

FPGA IO should be familiar

from earlier exercises. Make

note of how you pass the

reference to each IO call .



NOTE: Run the following experiments with

the DaNI ‘up on blocks’ rather than on the

‘DaNI-dyno’.

You want the wheels/drivetrain to run with no

external load.



Here is code for a single-channel,

reading one encoder and driving

just one motor.

You can just adjust the PWM level

on the front panel.

This quick VI would allow you to

measure the static relation

between motor speed and

‘modulation’ level.



Final experiment for Exercise 3 of Lab #1:

Implement a ‘smooth step input’ to measure the transient response of the motor

output shaft speed.

By a smooth step, that means not a ‘harsh’ step input. However, provide a way to

‘sharpen’ the transition from initially zero to a steady-state value.

Run at least three cases, ‘stepping’ the PWM values to achieve roughly about 5, 10, and

15 rad/sec (this last being about the max speed for this motor).

Capture your speed transient response using an output graph on the front panel to

visualize the motor output shaft speed.

Assess the dynamic characteristics. Does the system appear to be dominantly 1st order,

2nd order?

As discussed in class, the goal is to identify key model parameters for an ‘experimental

model’ of the DaNI drivetrain. The working hypothesis is that the relation between motor

speed and modulation level can be represented by 1st order dynamics.



So, to complete a Lab #1 report, do the following:

1. Measure the motor output speed vs. ‘modulation’ level. Report modulation level in

normalized form; i.e., [-1,1] and output speed in rad/sec. Measure at least 5 points in

forward and 5 in reverse rotation.

2. Plot your experimental results with results using your model for the DaNI drivetrain.

Remember, your HW #1 simulation should only be for the drivetrain, not for the whole

vehicle when you make this comparison. Plot speed vs. modulation level together with

the experimental data. What is the slope? (units of rad/sec for ‘normalized’ case; we’d

multiply by 500 usec to get proper units). This is the system ‘static gain’, K.

3. Did you observe any dead-band in the speed-modulation relationship? What is dead-

band? (Do a little research on that)

4. Submit a short report on Lab 1 that summarizes Exercise 1 and 2 on 1 page and Exercise

3 on two pages. Provide screenshots only if there are significant differences between

how you completed these exercises compared to the guidance provided on these slides.

5. Provide one additional page explaining any differences in HW #1 predictions of steady-

state speed and what you measured in lab. Can you think of any ways to improve the

model to better match the experimentally determined results?

6. Finally, in no more than two more pages, use results from your dynamic experiments (the

step results) to propose an experimental dynamic model. If it looks first order, what is the

‘tau’ value (the effective system time constant)?



1. Measure the motor output speed vs. ‘modulation’ level. Report modulation level in

normalized form; i.e., [-1,1] and output speed in rad/sec. Measure at least 5 points in

forward and 5 in reverse rotation.

2. Plot your experimental results with results using your model for the DaNI drivetrain.

Remember, your HW #1 simulation should only be for the drivetrain, not for the whole

vehicle when you make this comparison. Plot speed vs. modulation level together with

the experimental data. What is the slope? (units of rad/sec for ‘normalized’ case; we’d

multiply by 500 usec to get proper units). This is the system ‘static gain’, K.

3. Did you observe any dead-band in the speed-modulation relationship? What is dead-

band? (Do a little research on that)

DISCUSSION ON RESULTS



Here is what I measured for the left motor on the DaNI on my bench. The data was fairly

symmetric, so only positive rotation is shown here.

A linear fit is used through the data, but there is a ‘dead zone’ because the motor controller

is set to ‘exponential model’. Is this due to the controller only or also to motor ‘stiction’?

“Dead

zone”

Slope

here is

0.044

Used these parameters to

force the intercept through -7



The controller was disconnected from the motor and the ‘open’ circuit output voltage

measured with a DMM set to measure the DC voltage of the PMW signal.

Pretty much saw a dead zone trend here as well. However, there was a region as shown by

the dashed ‘blip’ where the DC voltage seemed to increase and then decrease before it

climbed as shown above 200 usec. This is was repeatable.



So, what happens if you set the Sabertooth controller to ‘linear mode’? Well, it is not what

you’d think. The results for the open circuit DC voltage output are shown below.

The DC voltage does not climb linearly, instead following a sort of S-curve (fit by a

Logistic function – green). The speed vs pulse width had similar trend. Both the voltage

and the speed saturated at a low pulse width. This is not desirable.



DYNAMIC Experiments An open loop step response is shown below. Here the motor

was at rest and 500 usec pulse width was input.

To analyze this data, you can look at ways to save a file in the VI or even use other

methods such as Network Streams or Shared Variables. A simple way is to just zoom on

the data you want to analyze as shown above…then ‘export the data’ as shown on the next

slide. Paste into a text file.



Time Speed (rad/sec)

395 0

396 0

397 4

398 10

399 12

400 13

401 16

402 14

403 16

404 16

405 16

406 16

407 15

408 17

409 17

410 15

411 16

412 16

413 16

414 16

415 16

416 16

417 16

418 16

419 16

420 16

421 16

422 16

423 16

424 15

425 16



This VI was used to fit

a 1st order step

response to the

measured data.

Tuning to the 1st order

model shows the effective

time constant is about

0.045 sec.



Has anyone tried to unravel the

Encoder Loop code?

Why is the resolution of the velocity

measurement 1 rad/sec?



In class, discussed a little bit about my theory on why we get 1 rad/sec resolution for

encoder-based speed measurement (I reserve the right to correct myself later)

First, note that ‘velocity interval’ is defined as 640000 ticks, or 16

msec (since the FPGA tick is based on 40 MHz).



Note that the tick counter is initialized, call that t0. Each iteration has a tick count by the

counter in the loop, so you calculate a dt=tc-t0 difference. If dt<640000 ticks (16 msec), then

the count on each encoder and the velocity estimate is equal to the previous value (False case),

and initial time stays at t0. Only when dt>=640000 are the count and velocity values updated.

This ensures that sufficient time has passed to get plenty of counts for a decent estimate but it

also costs you resolution in your estimate of angular velocity.



rad

pulses rev

secpulsestick

tickrev

2

1

cyc

cycp

N

TN

π

ω

⋅ ⋅ ≅ ⋅

from encoder loop, ppi

from encoder spec, 400 ppr

from FPGA spec, 40 MHz

cyc

p

cyc

N

N

T

=

=

=

6

1

40 10 ticks/seccyc

T =⋅Note, using ‘interval’ or ‘tick’ synonymously.

Recall….



[ ] radsec

rad

rev

secpulses

tickrev

tick

2

1 11 pulse 0.98

640000 cyc

cyccycp

NN

TN

π

ωδω δ

⋅ ∂ = = ⋅ ⋅ ⋅ ⋅ =

∂

So, we want the ‘resolution’ for our encoder speed measurement. We need to use our

formula for angular speed, but take the differential relative to what you can measure, which

is just the number of pulses. If you’ve every learned about how to get uncertainty in a

measurement, this is the same thing (propagation of error method). Here is a calculation for

estimating the resolution (or quantization error) in the encoder speed measurement based on

this approach.

Note that you need to include the inherent ‘velocity interval’ in ticks (the observation

period), assume a constant here (you could include it as another variable). So the value

found seems to be what is observed in our measurements.

However, and oddly, if you made an estimate with a shorter velocity time interval, then the

resolution would be worse. That seems to go against the rule that ‘sampling faster’ gives

you better estimates. To get a better estimate you actually need to observe pulses for a

longer time period, but then you have to make the control loop time longer - not always

possible. So, the choice of 16 msec appears to be a compromise: long observation, fast

enough control loop rates (and the use of fixed-point math).

CyVS: Lab 1 - me.utexas.edulongoria/CyVS/Lab1/Lab1_sbRIO_familiarity_v3.… · CyVS: Lab 1 Begin:...

Documents

Transcript of CyVS: Lab 1 - me.utexas.edulongoria/CyVS/Lab1/Lab1_sbRIO_familiarity_v3.… · CyVS: Lab 1 Begin:...