Você está na página 1de 7

EE 472 Lab 3 (Group)

FreeRTOS, Pulse Width Modulation, Drone


University of Washington - Department of Electrical Engineering

Introduction:

In this lab, you will be porting over some of your tasks from Lab 2 to the FreeRTOS
operating system. In addition, you will implement a pulse width modulation scheme,
work with more inputs, and start to control the drone.
Lab Objectives:

1. Use ISRs and related code to measure the frequency of a signal applied to an
input.
2. Generate an accurate and stable Pulse Width Modulated (PWM) signal on a
digital output.
3. Transition to the FreeRTOS embedded real-time operating system.
Prerequisites:

Familiarity with C programming, Eclipse and the IDE development environment,


debugging, and the Make Controller board. Use the class notes, slides, text, and
supplemental materials to brush up on concepts related to this lab. Make sure to cite
any materials or source code used from outside this class.
Theme for Labs 2-4 and Background:

For Labs 2-4, we will be implementing a subset of an autonomous unmanned aerial


vehicle (drone). Drones heavily depend on embedded systems as they take input from a
variety of navigation sensors and provide timely control. For Lab 2, you will learn about
building a scheduling algorithm by using external sensors and actuators to simulate
controlling a drone. In Labs 3 and 4, you will control an actual model drone (The Parrot
AR Drone - http://ardrone.parrot.com/parrot-ar-drone/usa/ , see Figure 1) and program
autonomous maneuvers using the real time sensor data coming from the drone itself
while it is in flight. You will be responsible for eventually implementing the control tasks
using a network connection between the Make platform and your drone.

Figure 1: The AR Drone platform.

In this lab, we will implement a scheduler for controlling a motor using PWM, displaying
sensor data to the LCD, taking input from the keypad, and transitioning to the FreeRTOS
real-time operating system kernel. We will also be giving you some precompiled drone
libraries that allow you to initialize and control the drone.

Scheduler

In this lab, we are transitioning to the FreeRTOS real-time operating system kernel. This
will take care of scheduling for you. Remember that FreeRTOS is pre-emptive. This
powerful feature dramatically changes how you should write your tasks (and makes them
easier!). See the class notes and text book on pre-emptive scheduling.
Since FreeRTOS has its own timing interrupt, you can remove your ISR and timer
initialization for the basic 1ms clock when you get to that point. One strategy for this lab
is to get some of the simple tasks (defined below) working with your scheduler from Lab
2 first and then work on porting your code over to FreeRTOS, but its your choice.

Tasks

You must implement the following tasks:


Timing.
Continue with your timing ISR from Lab 2 to get the new tasks working. After the
transition to FreeRTOS, all timing should now be done by using the FreeRTOS
Sleep(n) call.

Motor Speed Sensor on 472 Board


This task must measure the motor speed by looking at the time between pulses
from the photo sensor on the motor board. Using the rising edge on the photocell
pulse and the difference between subsequent ones gives you the period of the
pulse (take a look at Lab3_Examples.zip on how to setup a rising edge interrupt).
Each pulse corresponds to a full revolution of the motor so that if we need 200
RPM for the motor, we must see 200 pulses per minute. The motor speed
measurement task must convert the measured pulse period into RPM.
PWM Generation and Motor Speed Control.
This task must generate a PWM output on a digital output line (you cant use the
built in PWM function). Use a timer to keep track of the switching time. The
PWM period can be 100ms. The duty cycle of the PWM output must be set by
your controller from Lab 2. You can think of one direction of your joystick
controller as an accelerator to get the motor spinning to a certain speed. Connect
the PWM signal to the motor to test the motor and your motor speed sensor. Use
the oscilloscope for debugging. If you already implemented a proper PWM
scheme in Lab2, then you just need to add the MotorSpeed Sensor task and
feedback control, and you are done with that part of Lab 3.
Keypad
Wire up (see datasheet and notes in the Lab 3 directory) and test the keypad. You
dont have to use every key if you want to save your digital pins. The keypad is
going to be your manual override and allows you to control your drone (in
addition to or complementary to the joystick). For testing, you can use the LCD or
flash the LEDs. Make sure your keypad code works before using it to control the
drone! Check out the data sheet and the keypad_notes.zip for help with the
keypad. The keypad is just a matrix of switches.
Joystick
You will use your joystick to control the drones movement. It is up to you on
how you want to use the joystick and keypad. You could have a button on the
keypad that causes the drone to take off and land, while the joystick on the
controller moves the drones around. Make sure your joystick code works before
using it to control the drone!
Drone Control.
This part of the assignment obviously requires FreeRTOS and you should use the
included dronecontrol code as a starting point. Weve provided libraries compile
using two different versions of GCC.
You will finally get to control the drone. A complete overview of using the drone
will be given in class. There are a lot of precautions to take. Do not try any
advanced maneuvers until your application is tested and debugged. A damaged
drone will add significant down time to your project. Do not attempt to control the

drone with any other client or update the firmware. We have a custom firmware
on these drones that is specific to this class.
You should have task(s) that basically respond to joystick and keypad requests for
controlling the drone. You are welcome to map the various controls to whatever
key (takeoff, land, hover, left, right, forward, back, rotate left, rotate right, up,
down). I would first make sure takeoff and land work very well before moving to
more advanced maneuvers. Remember from HW1 that the drone needs to see
some kind of command (every 20-50ms) so that it doesnt think the connection is
lost else the watchdog bit has to be reset. You will have a loop that makes sure to
keep issuing an appropriate command. For instance, if you havent taken off yet,
you will keep sending it land every 20 ms or if you are hovering then you would
keep sending it the hover command. If you are controlling the drone, then clearly
you dont have to send anything additional (just keep repeating).
We have implemented the communication protocol tasks for you in this lab in the
form of pre-compiled libraries. For lab 4, you will be writing some of these on
your own. The function headers in the various header files will give you
information on what the functions are and what they do. Only start controlling the
drone after you have your keypad and joystick working!! The sample code we
have provided, simply boots up the drone, takes off, spins a little, and then lands.
Navigation Data
This will grab navigation data from the drone and unpack some of its content. The
navdata includes a bunch of sensor values including the altimeter, gyro, and the
camera. Data structures for the navdata are defined in the nav data header files.
There is A LOT of data being sent from the drone, thus the structs are very
complex. (Ex. Here is how you get the altimeters data:
navdata_unpacked.navdata_demo.altitude)
Youll do more with this data in Lab 4, but you can start playing around with the
sensor values you can get.
Display
This task will display any relevant information to the LCD or LEDs. Be creative.
You can show the RPM from the motor tasks as well as the navigation data
(altimeter, roll, pitch, yaw, etc). Work on this task last after you get the basic
controls working.

*Note that you are allowed to break up any of the task mentioned above into smaller
tasks if you think it makes your design better.

Implementation Advice

Use can use the supplied Lab 3 code as a starting point for this lab. Also, refer to the
example FreeRTOS implementation also supplied for Lab 3 in helping you learn how to
use FreeRTOS (Lab3_Examples). You will be referring to http://www.freertos.org/, the
make API, the notepack, and the text book for this lab. Also, check out the Make API:
http://www.makingthings.com/ref/firmware/html/group___r_t_o_s.html
You will have to port your application to FreeRTOS.
1. One by one, port your tasks to FreeRTOS. Start with the simplest tasks. What are
the issues and changes required for each task? Document these in your report.
2. Think about how can you arrange task priorities so that all of your real-time
requirements are met?
3. Make sure to observe all output to make sure your tasks are working correctly.
The Make folks have written wrapper functions around the FreeRTOS calls which we
will sometimes use for convenience. You are free to use either the wrapper functions or
native FreeRTOS calls. See the notepack notes on FreeRTOS. We will also go over
FreeRTOS in class.
One of the advantages of using heavy is that OSC debug is enabled, which allows you to
print debug messages to the screen of the PS (as long as your USB cable is connected).
http://www.makingthings.com/documentation/tutorial/programming-the-make-controllerkit/debugging
http://www.makingthings.com/ref/firmware/html/group___debug.html
However, OSC debug is a huge memory hog and can cause a lot of problems with your
tasks. Make sure to disable as much of it as possible and use it sparingly.
Remember that in FreeRTOS you dont have a main.c. Main is already built in. The entry
point for your application will be void run(), which will create and insert your tasks into
the FreeRTOS scheduler (see make.c in the sample code).
One suggestion for Lab 3 is to break it up into two parts. The first is to get the motor
speed sensor and the pwm working first (you can even just use your Lab 2 scheduler for
this) and then just compile it and be done with it. In the second part, just focus on the
drone related tasks using FreeRTOS.

Testing Requirements

Lab 3 will be tested using procedures and methods similar to Lab 2. For example, PWM
outputs will be verified with the oscilloscope or by observing the motor. Drone control
will be tested using the keypad and/or joystick (depending on how you implement it).
Deliverables

Turn in your commented source code and your compiled bin file(s) to the website by the
due date specified on the class schedule. You will be asked to flash your board with the
submitted bin files for the demo. Do not forget to use proper and consistent coding style;
including proper comments. Also turn in a document that identifies which portion(s) of
the project everyone worked on.
Grade breakdown:

70 points total:
PWM and motor speed control: 10 points
Keypad input and joystick input work: 15 points
Display works and shows nav data: 10 points
Working drone control: 15 points
Lab report: 15 points
Commented and well organized code: 5 points

Accessories Board
The accessories board contains several devices for our software to interact with. The
schematics can be found below. Pinouts are shown for the black and white wire clamp
terminal block (pin number shown in white on the PCB. The test points are small loops to
which you can hook your scope. The DC pager motor is wired to the two pads shown in
parallel with D5. The two BJTs (T1 and T2) are biased to switch fully on or off according
to an input on pin 6 of the terminal block. Note that power and ground are prewired via
solder connections to the board so it is always energized when the power switch is on.