Report - Raymond W. Mui
RoboTank Final Project Electrical Engineering 472 University of Washington Name Student ID Raymond Mui 1134650 Andrew J. Townsend 1263997 James Goin 1137690 Abstract For the final project, we finish development of the RoboTank and implement Bluetooth communication.​
This report will define the requirements of the system, describe the software implementations and test specifications. The RoboTank implements a Real­Time Operating System (FreeRTOS) which uses a preemptive priority scheduler. ​
The RoboTank System can be modularized into five subsystems. These subsystems are the distance measurement, motor controller, keypad, OLED, and bluetooth subsystems. ​
The state of the vehicle is displayed on the OLED of the user controller. Using the controller, the user can select between manual, semi­autonomous and autonomous control of the RoboTank. ​
It will display the inputs of each of the four sensors and will show the current state of the tank. The sensors read four different distance values to avoid obstacles, drive the motor controller (depending on the selected mode) and activate the alarm system. Figure 0.1
Fully Built RoboTank 1 Table of Contents Abstract Table of Contents Introduction Design Specification [Section 1.0] Distance Measuring Subsystem [Section 1.1] Motor Subsystem [Section 1.2] Keypad Subsystem [Section 1.3] Display Subsystem [Section 1.4] Bluetooth [Section 1.5] Software Implementation [Section 2.0] Distance Measuring Subsystem [Section 2.1] Motor Subsystem [Section 2.2] Keypad Subsystem [Section 2.3] Display Subsystem [Section 2.4] User Manual and System Functionality [Section 3.0] Analysis Of Why The Project May Not Have Worked and What Efforts Were Made To Identify / Fix the Issues [Section 4.0] Test Plan [Section 5.0] Test Specification [Section 5.1] Test Cases [Section 5.2] Conclusion Member Contributions Appendix Extra Credit Features Included 2 Introduction
In this lab we finish development of the RoboTank system project. In previous project phases we have built a foundation of knowledge such as peripheral support and learning different design approaches to modularize a large system. For peripheral support we have used: the five onboard Stellaris buttons (up, down, left, right) via GPIO, an external LCD interfaced over GPIO, LEDs via GPIO, analog sensor input and sampling via A/D conversion, timing using General Purpose Timers, and interrupt control. For design partitioning approaches, we first implemented the functionality in a main() while loop and learned the constraints such a design imposes on a system. Next we added interrupts and moved time critical functionality into interrupt service routines while keeping time consuming non­critical functionality in the main() while loop. We learned the increasingly complex constraints imposed on such a design, particularly around sharing resources with multiple threads of execution (main loop and interrupt service routines). We will shift to using a preemptive priority scheduler based Real­Time Operating System, FreeRTOS, which includes fundamental APIs for proper use in such a system. Using these APIs involves an understanding of their use cases, their requirements, and the ability to make design decisions. The objectives to achieve include understanding and defining the system: requirements specification, design specification, implementation, and test plan. We will use this project to continue working with the development life cycle of an embedded system. To that end, we will begin creating formal requirements, structured specifications, modular designs, implementations, and test plan that trace back to the requirements. 3 Design Specification [Section 1.0] In this project we are required to develop a functional RoboTank system and controller that operates via Bluetooth Serial Port Profile (Bluetooth SPP). The RoboTank system is a Real­Time Operating System that includes the implementation of GPIO peripherals for a keypad, OLED user­interface, ADC sensors, alarm system, two pulse width modulators (PWMs), and an UART port for Bluetooth Communication. Both the RoboTank and controller run using interrupt and task driven functions. All data must be safely shared and protected using semaphores. Protecting the shared data will prevent critical failure of the RoboTank system. The final product will satisfy these basic requirements and additional features: 1) A user­interface that is controlled by the keypad. The menu will allow the user to access sub­menus and choose between different modes. This interface will display information about the current state of the RoboTank on the controller OLED. 2) Use instantaneous and average ADC sensor data to display the distance. This data will be used to help the RoboTank system avoid objects. 3) Generating two PWMs to control the motors of the RoboTank System. 4) A set of motor control commands that will adjust the PWMs to drive the RoboTank forward, reverse,left, right, forward­left, forward­right, reverse­left, reverse­right, clockwise rotation, and counter­clockwise rotation. 5) The controller and RoboTank will communicate through Bluetooth. 6) An auto­stop feature that stops the Robo­Tank when an object is too close to the front sensor. 7) An alarm system that increases in frequency when the back sensor sees an object while reversing. 8) A semi autonomous and autonomous mode giving the ADC sensors some and full control of the RoboTank system. RoboTank Inputs: ADC sensor data and receive control commands via UART using Bluetooth SPP. RoboTank Outputs: PWMs the control the motor and the operation of RoboTank. Controller Inputs: User key presses to select modes, and control commands. Controller Outputs: Control commands sent out via UART using Bluetooth SPP. 4 Figure 1.1 RoboTank Functional Diagram Figure 1.2 Controller Functional Diagram 5 Distance Measuring Subsystem [Section 1.1] The distance measuring subsystem will use four Sharp GP2Y0A21YK0F ADC sensors. Each channel will take 4096 instantaneous samples per second, accumulate these samples, copy the accumulated value and safely share it with the ADC Task in the system. Once 4096 samples have accumulated, the accumulated value will reset to zero and the ISR will set a flag for the ADC Task to call the average function. The average function will process averaged samples by retaining the residual lower 6 bits of resolution for a pseudo extra 6 bits of resolution. Once the averages are produced for each channel, a transform lookup table function is be called by the ADC Task and converts the averages to a distance values in millimeters. The distances are then safely shared for use by the motor control and OLED Display subsystems. Valid Input Voltage Values and Corresponding Distances Minimum input voltage: 0x0000 = 0.0 VDC = 800 millimeters (capped at max. distance) 0x2222 = 0.4 VDC = 800 millimeters (maximum measurable distance) Look up table will consist of 256 between 0.0 and 3.0 VDC 0xFFFF = 3.0 VDC = 70 millimeters (minimum measurable distance) Maximum input voltage: 0xFFFF = 3.3 VDC = 70 millimeters (capped at min. distance) Outputs of Distance Measuring Subsystem The outputs of this subsystem are the average and instantaneous values for each of the ADC sensors. These values output to the Motor Control subsystem and are used to help drive the motors in semi­autonomous and autonomous modes. The average ADC values also output to the OLED task where they are used to display the distance between an object and the RoboTank in millimeters. 6 Motor Subsystem [Section 1.2]
To control the RoboTank motors we will use the Toshiba TB6612FNG dual motor H­bridge driver IC. For each motor, the task will use two independent PWM outputs which are connected to the motor driver IC. The motor control task is responsible for RoboTanks movement straight in the forward direction, straight in the reverse direction, moving forward while turning right or left, moving reverse while turning right or left, rotating clockwise, and rotating counter­clockwise.The tank also provides a dynamically variable turning radius while in motion. The system uses five motor control GPIO outputs to achieve this: Standby, AIN1, AIN2, , BIN1, BIN2. AIN1 and AIN2 control the direction of motor A which controls the left drive motor on the tank. BIN1 and BIN2 control the direction of motor B which controls the right drive motor on the tank. PWM2 and PWM3 control the speed of the left motor and right motor respectively. Standby puts the motor controller in standby or in a state ready to respond to the direction and speed inputs. PWM1 is used for the backup alarm. The backup alarm only sounds when and obstacle is behind the tank while it is backing up. The GPIO outputs will be: ∙ Digital data ∙ Voltage range 0.0 to 3.3 VDC The PWM outputs will be: ∙ Digital data ∙ Voltage range 0.0. to 3.3 VDC ∙ Duty cycle: 0 to 100% The Motor Control Task takes three inputs:
1. A direction command
2. The instantaneous distance[4], one for each distance sensor.
3. The oversampled and averaged distance[4], one for each distance sensor The Motor Control Task outputs:
1. the left motor
2. the right motor 3. Back­up alarm
7 Keypad Subsystem [Section 1.3] The keypad is manually operated via an OLED menu driven user interface using five buttons: up/forward, down/reverse, left, right, and select. This subsystem uses the onboard Stellaris Board keys. The buttons are debounced in software and are active low. The buttons are sampled at a 100 Hz rate. Button inputs will be digital data with voltage ranging 0.0 to 3.3 VDC. On the controller of the keypad will output and control the Robotank via Bluetooth. Display Subsystem [Section 1.4] An OLED display will provide user interface information, such as obstacle distance readings from each directional sensor, feedback information of the key press and mode selection. This interface information is output to the OLED display. The OLED subsystem will take inputs from the motor control task for the state of the Robotank and sensor value from the SensorToOLED task. ​
Bluetooth [Section 1.5] We will use the Roving Networks RN­42 Class 2 Bluetooth Module to communicate between our Robotank and the controller. The Robotank will be set to Slave Mode when pairing to the controller which will be set to AutoConnect Master Mode. By doing this when the controller and RoboTank are powered on. The controller will search for the Robotank and automatically pair. By enabling the UART port of the Stellaris Board we will use Bluetooth SPP to send data from the controller to the RoboTank to drive it. 8 Software Implementation [Section 2.0] In this section we will discuss ​
our design starting from a top level functional view and block diagram on high level architecture. We will refine that view to present and explain each of the modules that comprise the major functional blocks. We will discuss the flow of control through the design. Also we will identify, discuss and explain the specific processes we have implemented in our design. Figure 2.0 Control Flow Diagram Distance Measuring Subsystem [Section 2.1] This subsystem waits for 1200 ms to receive a sum of 4096 distance values from timer interrupt in the xSumQueue. When it receives it, the sums are stored in a buffer and the averages are then calculated and sent to the average distance queue, xAvgDistQ. Control is then passed to the sensor to OLED task and the task waits for new input from the queue. If it does not receive any values within the limit, priority is set to the highest and an error is drawn to the OLED before entering an infinite loop. We chose to set up our ADC task in this manner because it shares the average data safely between the Distance Measuring, Motor Control and the OLED Subsystem. 9 Motor Subsystem [Section 2.2] Tank Movement Left Motor Speed Right AIN1 AIN2 BIN1 Motor (Left) (Left) (Right) Speed BIN2 (Right) Standby Forward Full CW Full CW 1 0 1 0 0 Reverse Full CC Full CC 0 1 0 1 0 Left Full CC Full CW 0 1 1 0 0 Right Full CW Full CC 1 0 0 1 0 Forward Right Full CC Slow CC 0 1 0 1 0 Forward Left Slow CC Full CC 0 1 0 1 0 Reverse Right Slow CW Full CW 1 0 1 0 0 Reverse Left Full CW Slow CW 1 0 1 0 0 Standby X X X X X X 1 Figure 2.1 Motor Control Logic The motor task on the slave was implemented with three main drive types: Manual, Semi­Autonomous, and Autonomous. In the case that manual mode is selected, every 10 ms or new key press whichever takes longer, the keys are used to choose the current setting of the motors' direction and speed as well as the state of the buzzer and the direction drawn to the OLED. The allowed inputs are left, forward left, forward, forward right, right, reverse right, reverse, and reverse left. All other inputs will result in standby. Also, if there is an obstacle in front or behind when a forward or reverse input is given respectively, the motors will be set to standby. After the motors are set to the given input, the PWMs are enabled (after the first run through this step is unnecessary). In order to return to the top menu select and all 4 directional keys must be pressed. In semi­autonomous mode, the user uses the up and down keys to select the appropriate direction and seconds they want to go. Once a value is selected an FSM is used to properly set the motors to match. If there is an obstacle in front or behind, it will stop the current command and wait for the time to end before asking for a new input. The autonomous mode 10 follows a wall on the left side by going straight if there is a wall and turning left if it is too far and turning right if there is an obstacle in front of the tank. Keypad Subsystem [Section 2.3] The keypad subsystem uses an interrupt driven task to get the key value. If a key has been press we check if the key has been debounced. If not we set the pastKey to getkey(). Then we check if getkey() and pastKey are equal. If so we check if the debounce count has exceeded 256 (if we are debouncing) and increment accordingly. Otherwise we reset the debounce count. The RoboTank (slave) key task gets the value in the UART data register and masks it for just the key presses and then overwrites the key queue so that it can be used elsewhere. The controller (master) key task gets the current tick count and then disables the debouncing interrupt to protect the debounce count, saves it locally, and then reenables debouncing interrupt. If the debounce count was below required amount, both keyOut and the past value are zeroed. Otherwise, if the continuous press variable is true keyOut is set to the current keyVal gotten via getkey(), else it is set to keyVal only if it is different than the last keyVal. keyOut then overwrites the current value in the xKeyQueue to be used elsewhere. The task then delays for 100 ticks since it was measured at the beginning. Sends keys values out via Bluetooth SPP. We chose this design because we believed this was the safest and the easiest way to transfer and share data. Display Subsystem [Section 2.4] The OLED Display subsystem draws the string written at the specified x and y position on the OLED display and then draws a column of options below it. It then allows an option to be selected using the up, down, and select keys and returns the index of the selection. All writes to the OLED are protected with the OLEDMutex. First the directions string, written, is drawn to the given position on the OLED and then each of the option strings are subsequently drawn below it in order. A cursor is then placed next to the first option and it waits for a keypress. Once it gets a key press, it erases the cursor and then draws a new cursor above if the key press was up, below if the key press was down, and redraws it to the same position otherwise. In the case that the key press resulted in going off either end of the list, the cursor will wrap around. Once a certain option is selected with the select button, it waits for the select button to be unpressed before returning the index of the option selected. After taking in the average distance value, this value needs to be converted into a millimeter distance value. The way we did this was by shifting the inputted 16 bit value 8 bits to the right, the value is converted to an 8 bit value and then used as an index for the conversion table and returned (see common.c , line 58 and 113 for reference). We only took the top eight bits because we designed our lookup table to contain 256 values and that provided a good enough degree of accuracy. We obtained these values by choosing points off of the Sharp GP2Y0A21 Distance vs. Voltage plot then finding the correct number of values we wanted in between and interpolated the data on MATLAB. 11 Figure 2.3
Sensor Distance vs. Voltage Plot Figure 2.4 MATLAB Code used to create lookup table 12 User Manual and System Functionality [Section 3.0] Initial Display Screen Arrow Keys are shown to the left and select button to the right. Press select to begin. All four proximity sensor distances are displayed in millimeters at the bottom left of the display. Control Mode Selection Menu Press up or down to select either manual, semi­autonomous, or autonomous driving modes. The ‘>’ identifies the currently selected mode. Press select to enter the currently selected mode. Manual Mode: Press the directional keys to move. The RoboTank can move forward, forward left, forward right, reverse, reverse left, reverse right, turn left and turn right continuously. RoboTank will go as long as you hold the key; however if there is an obstacle in front or back while reversing the tank will stop. Semi­Autonomous Mode: Choose direction and duration and RoboTank will follow the command. Autonomous Mode: Once in this mode the RoboTank will move by itself. Press all 5 keys to return to the Initial Display Screen. Once in a selected mode, the mode is displayed on the top left. Underneath it displays the current operation of the tank. When no keys are press the motor controller enters standby mode. All key presses directly coordinate to the direction the tank will drive, including combination such as forward right. If all five buttons are pressed at the same time, you are able to re select a control mode. 13 While in manual mode, if an obstacle is in the way of the tank while driving it displays the location of the collision in nautical terms, and prevents the tank from being able to move closer. If you hold select while driving you are able to override this prevention. Both of the tanks DC motors are controlled via PWM. The image to the left shows both motors at high speed moving in the same direction. Signals to the motor controller signify direction of the motors. The PWM signals to the left show the tank driving with one motor faster than the other. This would be used to turn the tank while still moving in that direction. In order to identify direction of the tank and alarm is sounded when moving in reverse. This alarm increases in pitch as the tank gets closer to an object. Analysis Of Why The Project May Not Have Worked and What Efforts Were Made To Identify / Fix the Issues [Section 4.0] This project had a plethora of issues that resulted in the need to debug. Many hardware issues occurred such as possibly damaging our initial motor controller. This was somewhat beneficial because it allowed us to double verify each modularized part of the RoboTank system and controller. Once that was replaced another issue that showed up was that the ADC values were not reading correctly. The reason the ADC sensors were acting this way was because the Stellaris Board was not getting enough power from our AA USB power supply. The batteries had drained too quickly. Despite all these errors we were able to create a fully functional RoboTank system that could operate manually, semi­autonomously and autonomously. 14 Test Plan [Section 5.0] In order to verify that our design meets the original requirements we will need to test that the motor controller is outputting correctly based on its inputs, verify that both bluetooth modules sync up and can send and receive messages within good timing, ADC’s are correctly reading and calibrated, PWM’s are outputting the correct signals to the motor controller, the OLED is correctly displaying, keypresses are debounced and set for both driving and menu navigation and last but not least the tank can both drive manually semi­autonomously and autonomously. Test Specification [Section 5.1] Test Test Limits Motor Controller The motor controller is controlled by 5 GPIO ports to set an operational mode and 2 PWM’s to vary output power. Each operational mode will be tested for correct output to motors. See table above. BlueTooth Bluetooth can be tested through sending and receiving characters. This is easy to do with a Bluetooth SPP app for android devices. The baud rate of the bluetooth modem needs to be 115,200. ADC’s All four ADC’s will be tested for correct distances measured. The maximum distance is 800 mm away, anything closer than about 70mm ends up being inaccurate. The ADC’s must read 4096 samples per second. PWM’s Testing pulse width, duty cycle and frequency for different requests such as driving forward, turning, turning while moving, etc. OLED Write speed, too fast become blurry and too slow blinks. Testing different locations and different strings. KeyPresses Testing that keys are properly debounced and single key press is not recorded multiple times. Test that for the menus each press counts as one action, however for control holding the key counts as continuous input. Manual Driving This test is a combination of all of the above. Testing that each key on Master directly relates to controlling the tanks direction of movement. Semi­Autonomous Driving Send the commands and see if the RoboTank behaves accordingly. Autonomous Driving This test is also a combination of all of the above. Testing will involve using multiple different environments for the tank to drive through. This will be a combination of control logic and calibration. 15 Test Cases [Section 5.2] Test Test Cases Motor Controller In order to test the motor controller use the table above and verify that the given GPIO ports output the right combinations when giving a motor request. Once all inputs to the motor controller are verified to be what is on the table above, begin testing the outputs on the motor controller. Make sure to test all drive modes which includes forward, backwards, right, left, forward right, forward left, backwards right, backwards left and standby. Based on the orientation of the motors this may not line up perfectly with the table above and may have to be adjusted to accomadate. BlueTooth The easiest way to begin testing the bluetooth is to use the app Bluetooth SPP for android phones. Make sure the bluetooth device is properly connected and sync it with the app. ….. ADC’s An easy test to start off with for the ADC’s is a simple binary setup. If distance is less than a certain value than light the LED. This is an easy way to test if the ADC are initially working. From that point on the ADC is verified to be working and next test will be to determine the actual distance. This can be done, as mention above, by creating an interpolated lookup table of distances. The maximum distance is 800m and distortion occurs when closer than 70mm. Once this table is created, display the value to the OLED and verify that each sensor is recording an accurate reading. PWM’s The PWM’s can be tested by plugging the PWM GPIO ports directly into an oscilloscope, hitting auto set and viewing a repeating oscillating unit step function. If nothing shows up then the ports were most likely not enabled correctly. From the oscilloscope you can measure the pulse width. Make sure it lines up with what you coded. You can use to test PWM changes that occur during driving also, such as driving while turning. OLED In order to test that the OLED is working properly we make sure we set each task to the correct priority that we want and that only one task can write to the OLED at a time. We will verify this by using the menu and see if the characters on the screen get distorted or not. KeyPresses Press the keys super fast, or hold the key for a long time . Manual Driving Press the directional keys and see if the RoboTank is driving the correct way. 16 Semi­Autonomous Driving Send command via bluetooth and see if the RoboTank moves in the corresponding direction and duration. Autonomous Driving Verify that the RoboTank is following the left wall algorithm. Conclusion The focus of this lab was learning to implement a Real­Time Operating System, using a preemptive priority scheduler FreeRTOS and to finish development of our RoboTank system. Our goal was to design a system that met time constraints of the keys and ADC sensors to produce a tank that could be manually controlled and will avoid collisions with obstacles(and later semi­autonomous features). In order to accomplish this task we needed to understand the overall system and define requirement specifications, design specification, and test planning. We also needed to understand the fundamental APIs for proper use of FreeRTOS. Once this was done we began our implementation and tested each subsystem individually to verify functionality before putting the systems together. ​
In order to have accurate transmission of shared data between different processes and threads, all data that is sent and received between the two must not be allowed to read or written to at the same time due to the ability of multitasking to split any operation that is not atomic. This can possibly result in incomplete read and/or write operations. In order to prevent this accesses to shared data must be controlled such that in the case of a semaphore (or mutex), the data is associated with another inter­task communication that disallows more than the allowed number of threads/processes (typically 1) to access a protected communication at the same time. Alternatively, using a secondary data storage like a queue allows for the data to be stored into a queue and fully entered before it can be read out of the queue. Both of these examples result in the data being unable to be corrupted between tasks avoiding potentially catastrophic data reads. ​
Overall, our group was able to come to an appropriate level of understanding and confidence in our ability to design Real­Time Operating Systems. Member Contributions All members put in approximately equal amounts of time. We rotated having at least two of us at the lab, most of the time all three. We worked multiple late nights until (3­6am) on the lab. We spent two nights on the actual lab and then another two on extra credit. Signatures: James Goin
Raymond Mui
Andrew J. Townsend
17 Appendix Code is attached. Extra Credit Features Included Fully Autonomous Mode: Looks for a left wall and moves along it. Semi­Autonomous Mode: User selects duration and distance and RoboTank will move based off the commands. Alarm System: While reversing, the buzzer goes off and increases in frequency as the RoboTank moves closer to the object. Auto­Stop in Manual Mode: If there is an obstacle in front or behind the RoboTank will just stop and wait until the object is gone before it can move again. 18 
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF