B2023-lab1-velocity-control

pdf

School

Worcester Polytechnic Institute *

*We aren’t endorsed by this school

Course

2002

Subject

Mechanical Engineering

Date

Oct 30, 2023

Type

pdf

Pages

Uploaded by kaveermalik1211

Last modification: October 23, 2023 RBE 2002: Unified Robotics II B-Term 2023-24 Lab 1: velocity control Overview This document is divided into (1) background material, (2) pre-lab, and (3) post-lab. The background material is required to understand the pre- and post-lab assignments. The expectation is that you fully review the background material before lab. Be sure to read the post-lab before you start, so you know what data will be submitted. The weekly quiz (due on Friday at midnight) is based on this entire document and the four slide decks from our lectures, uploaded in Module I: velocity control on canvas. Resources • The Microsoft Visual Studio Video Guide by Prof. Miller . Invaluable resource to get a first idea of how to setup a project using Microsoft Visual Studio. Prof. Miller goes through the process of creating a project, embedding the Romi32U4 WPI library, and uploading a project to the Romi. • The Romi32U4 WPI library . Oﬃcial link to our very own (modified) WPI Romi library. I rec- ommend installing and using Microsoft Visual Studio and Platform IO for this course. • The Documentation for the Romi32U4 WPI library . Look at the documentation to learn more about the functions we use. Whenever you use a library function in this course, make an effort to understand it. Often times, it only takes half an hour of starring at a snippet of code and looking at datasheets until it all makes sense. • The Board schematic of our 32U4 control board. . This is one of the board schematics you should look at for extended periods of time to understand how components are (inter-)connected to other components including our microcontroller. • The Description of our magnetic encoders . This webpage gives you a concise summary of our magnetic encoders. It is the perfect entry point to go in-depth into aspects of the encoders. 1 Background material Robots require the capability to drive at known velocities and control their velocity upon changes in their environment (e.g., when they transition from a wood ﬂoor to a carpet). In this lab, you will learn how to implement a velocity controller for your Romi. Specifically, you will • read out your left and right wheel encoders and convert counts into tangential velocities.

RBE 2002: Unified Robotics II—Lab 1: velocity control 2 • output control signals to change effort to the left and right motors. • develop a PI controller that adjusts control signals based on encoder readouts. In the following, I will give you (1) an overview of velocity control and how the individual hard- ware components are interconnected, followed by in-depth discussions on our (2) magnetic motor encoders, (3) motor control, and (4) PI controller. 1.1 Block diagram Our two DC brushed motors are soldered to magnetic wheel encoders (Figure 1 ). The wheel en- coders possess four signalling pins. Pins M+ and M- are used for connecting our motors to motor drivers, whereas motor drivers are controlled via the microcontroller using pins PH, EN, and nSL. Pins Enc. A and Enc. B are connected to XOR gates, whereas Enc. B and the output from the XOR gate are being read by our microcontroller. Figure 1: Overview of hardware components involved in velocity control. Connections indicate number and type of signals between individual components. 1.2 Motor encoders Motor encoders are a very common sensor used to determine the speed and/or position of a motor. The most common forms of encoders use either light or magnets for their basic functionality. With light-based encoders, a wheel with slits or a zebra pattern is attached to the motor shaft and light is either passed through the slits or reﬂected from the light/dark pattern. Whether the light is detected or not determines the output of the encoder, HIGH or LOW . With magnetic encoders, the principle is similar: a special sensor – typically a Hall effect sensor – is used to detect the presence or absence of B-Term 2023-24—Prof. Markus P. Nemitz

3 RBE 2002: Unified Robotics II—Lab 1: velocity control magnets as they spin on the motor shaft. Your Romi comes with two magnetic quadrature encoders that can be used to keep track of the wheel motion. 1.2.1 Quadrature encoders Quadrature encoders get their name from the fact that they have two channels, which are staggered 90 degrees with respect to one another. The pulses are easily tracked with a microcontroller, and it’s easy to see that the faster the motor spins, the higher the frequency of the pulses. Figure 2: Oscilloscope capture of a quadrature encoder turning in the forward direction. The staggering of the signals in Figure 2 is particularly important. The reason is evident from Fig- ure 3 , where the motor is spinning in the opposite direction: when the motor is spun in the other direction, the channels switch places – instead of Channel 1 leading Channel 2, it now lags it. From the frequency and the order, then, you can calculate both the speed of the motor and its direction. Figure 3: Oscilloscope capture of a quadrature encoder with the direction of the motor reversed. 1.2.2 Magnetic wheel encoders on Romi Our magnetic wheel encoders possess two Hall-effect sensors that are shifted 90 degrees to one another (Figure 4 ). A magnetic disk consisting of six magnets is attached to the motor shaft. The Hall-effect sensors detect overlapping magnetic fields due to the difference in angles between Hall- effect sensors and permanent magnets. The two output signals from the encoder (OUT A or Enc. B-Term 2023-24—Prof. Markus P. Nemitz

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

RBE 2002: Unified Robotics II—Lab 1: velocity control 4 A, and OUT B or Enc. B) feed into an exclusive OR gate, which only outputs binary "1" when input signals differ, that is, for example, when Enc. A = 1 and Enc. B = 0. The output signal of the XOR gate and the signal of Enc. B feed into our microcontroller (AT- mega32U4). The XOR gate is attached to a PIN with interrupt function. Every time the XOR gate changes from binary "0" to binary "1" or vice versa, an interrupt service routine is executed, enabling the counting of pulses. Each encoder pair outputs 6 pulses per magnetic disk turn (360 deg); the XOR gate outputs 12 pulses per magnetic disk turn. Since the wheel encoder is connected to a gear box with 120:1 gear-ratio, it takes the robot wheel (independent of its diameter) 120 times more turns for a full revolution (360 deg) compared to the magnetic disk . Therefore, a count of 1440 counts (12 counts times 120) indicates a complete (360 deg.) revolution of the wheel. Figure 4: We attach a magnetic disk onto the encoder shaft; the magnetic disk has a total of six magnets that are aligned in 60 degree angles from one another. Figure 5: Encoder signals (Enc. A and Enc. B) are processed via a XOR gate and the output from the XOR gate is being read out by our microcontroller. The microcontroller is able to reconstruct Enc. A from Enc. B and the XOR-output signal. B-Term 2023-24—Prof. Markus P. Nemitz

5 RBE 2002: Unified Robotics II—Lab 1: velocity control 1.2.3 Timers in software Many microcontroller tasks need to be scheduled on a regular basis, from modulating a pin with PWM to reading a temperature sensor every 30 seconds. Depending on the need for precision timing, you may choose to use a timer written in software or a dedicated hardware timer built into the microcontroller. Software timers are an important tool for writing embedded code. Unlike hardware timers, which use dedicated peripherals to perform very precise timing, software timers typically use polling to check a clock against an alarm setting. For example, you have probably seen Arduino code that looks something like this: uint32_t nextTime; void SomeFunction(void) { if(millis() >= nextTime) { //do something interesting //... nextTime = millis() + INTERVAL; } } If SomeFunction() is called regularly, the code inside the timer will run approximately every INTERVAL milliseconds. Of course, there is no guarantee that the code will run at the exact timing specified, since the microcontroller might be doing something else at the precise moment millis() reaches nextTime . It follows that such a construction should be used only for non-critical timing tasks. There is one, somewhat esoteric ﬂaw with the above code, however. Namely, the code fails when- ever the millis() counter rolls over. A better way to write a timer is like this: uint32_t lastTime; if(millis() - lastTime >= INTERVAL) { //do something interesting //... lastTime = millis(); } Because of the way subtraction works in most microprocessors, this can manage clock rollover. In the lab activities, you will need to take repeated measurements. You’ll want to use a set schedule, but the precise timing isn’t too important. Therefore, the sensor scheduling is done using a software timer. B-Term 2023-24—Prof. Markus P. Nemitz

RBE 2002: Unified Robotics II—Lab 1: velocity control 6 1.3 Motor control Our motors are connected to DRV8838 H-bridge drivers allowing our microcontroller to control their speed and direction. Our motor has two pins (M+ and M-) that are connected to the DRV8388. The microcontroller controls the DRV8338 using three pins outputting control signals (PH, EN, and nSLEEP). Figure 6 indicates the signal combinations that allow for operating our motors in reverse, forward, or break modes. The speed of our motors can be controlled by making the EN-signal to a PWM-modulated output of our microcontroller. Figure 6: DRV8838 Low-voltage H-bridge driver. B-Term 2023-24—Prof. Markus P. Nemitz

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

7 RBE 2002: Unified Robotics II—Lab 1: velocity control 1.4 Controllers Computer programmers are accustomed to instructions that operate instantaneously and reliably. Both assumptions fail when writing code that controls a physical system. There are two major types of control systems: open- and closed-loop control systems. This section is derived from notes from Nathan Sprague from James Madison University. 1 1.4.1 Open-loop control Consider someone driving a car who starts at position x and wants to drive to position r (Figure 7 ). An open loop control scheme would be: def open_loop (x , r): # Calculate the distance to travel d = r - x # Cover that distance in one second for one second: drive forward at a speed of r / second Figure 7: Open-loop control system. The algorithm above is an example of an open loop controller. Open-loop control involves sending a sequence of control signals that, based on our understanding of the system we are controlling, should move the system into the target configuration. There are problems with this algorithm. First, cars are heavy. The success of this algorithm relies on the unrealistic assumption that we can in- stantaneously change the speed from zero to the desired value of r/s. Second, even after the car reaches the target speed, factors like friction and mechanical imperfections will make it impossible to perfectly maintain the speed. Over time, small errors in speed will result in significant errors in the final position. 1.4.2 Closed-loop control The problems with such naive controllers can be avoided by using closed-loop controllers instead. Closed-loop controllers continuously monitor the error in the system and update the control signal 1 Controlling Physical Systems, James Madison University B-Term 2023-24—Prof. Markus P. Nemitz

RBE 2002: Unified Robotics II—Lab 1: velocity control 8 to minimize the error (Figure 8 ). This approach tends to be more reliable because the controller responds to the actual state of the system and is able to make adjustments when factors that were not previously accounted for affect the system. Figure 8: Closed-loop control systems monitor the error between x and r continuously. The PID controller (Proportional, Integral, Derivative) is often used in closed-loop control systems. The next several sections will introduce the PID controller by describing each of the three terms. The following notation, illustrated in Figure 8 , will be used. x(t) - the state of the system at state time t. In our example from Figure 8 , this is the position of the car. More generally, this could describe any state variable that we are interested in controlling. y(t) - the measured state of the system at state time t. This could be the temperature of a room or the altitude of a drone. For now, we will assume that state information is provided by a reliable sensor. (In future tutorials we will consider the problem of estimating this value when sensors are absent or unreliable.) r(t) - the goal state or set-point at time t. Also called the target or reference. e(t) - error at time t. We will let e(t) = r(t) - x(t). In the case of the car, this value is zero when the car is at the goal position, positive when the car is to the left of the goal, and negative if the car overshoots and ends up to the right of the goal. u(t) - the control signal at time t. The interpretation of u ( t ) depends on the system we are attempting to control. In some cases u(t) might represent a low-level control signal like the voltage applied to a motor. In other cases, we may be working with a robot that allows us to directly specify a desired velocity or acceleration. In the case of our hypothetical car, we will assume we have a throttle function that takes a number in the range (-100, 100) where +100 represents “full speed ahead” and -100 represents “full reverse”. B-Term 2023-24—Prof. Markus P. Nemitz

9 RBE 2002: Unified Robotics II—Lab 1: velocity control Figure 9: Block diagram of closed-loop control system. 1.4.3 Proportional control Mathematically, we can think of the problem of developing a controller as finding an expression for u(t) in terms of e(t). One simple possibility is to follow the intuition that magnitude of the control signal should be proportional to the current error. In the car example, this means we should apply more throttle when the car is far from the goal location, and ease off as the car gets closer. This idea can be expressed as follows: u ( e ( t )) = K P ∗ e ( t ) The value K P is referred to as a gain term. This is a constant that determines how large the control signal will be for a particular error value. Doubling the gain doubles the magnitude of the control signal. Developing a successful controller involves selecting an appropriate gain value, either by analyzing the system or through trial and error. An example of a proportional controller would be: def p_controller (x , r , K_P ): while True : e = r - x u = K_P * e car.throttle(u) 1.4.4 Adding a derivative term One problem with our proportional controller is that it only considers the position of the car, not the speed. Intuitively, it seems that if the error is already deceasing quickly we should reduce the control signal to avoid overshooting the goal. These intuitions can be captured by adding a derivative term to the controller: u ( e ( t )) = K P ∗ e ( t ) + K D ∗ de ( t ) dt B-Term 2023-24—Prof. Markus P. Nemitz

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

RBE 2002: Unified Robotics II—Lab 1: velocity control 10 The term de ( t ) dt describes the rate of change in the error. This is negative if the error is decreasing and positive if the error is increasing. The value K D is a gain that is used to tune the impact of the derivative term. Using the derivative term requires us to know de ( t ) dt , but sensors do not usually provide direct access to this value. Instead, we need to estimate it by tracking the change in error over time. Even though the physical systems we are controlling operate continuously, our algorithms necessarily perform their steps at discrete time intervals. Assuming our controller is updated every ∆ t seconds , we can estimate the derivative as the slope between the two most recent error values: de ( t ) dt ≈ e ( t ) − e ( t − ∆ t ) ∆ t Discrete approximations like this are common in robotics and in other areas of scientific computing but they are not always made explicit. It takes some experience to get comfortable moving from continuous to discrete formulations. The following algorithm illustrates how we can use a discrete approximation to implement a PD controller. def pd_controller (x , r , K_P, K_D ): e_prev = r - x while True : e = r - x de = (e - e_prev) u = K_P*e + K_D*de car.throttle(u) e_prev = e Droop What happens when we try to apply the same controller when the car is located on a slight incline? In this situation the car never quite reaches the goal position. The car comes to rest at the point where the proportional force applied by the controller is exactly counterbalanced by gravity. Increasing K P will move the stationary point closer to the goal, but this controller will never drive the error all the way to zero. The situation where the proportional term is not suﬃcient to drive the error term to zero is sometimes referred to as “droop”. 1.4.5 Adding a integrative term The problem of droop can be addressed by adding one more term to our controller: u ( t ) = K P ∗ e ( t ) + K I ∗ Z t 0 e ( t ) dt + K D ∗ de ( t ) dt Where the derivative term allows the controller to look forward in time, the integral term allows the controller to look backwards in time. The integral R t 0 K I ∗ e ( t ) dt essentially accumulates the error that the system observes over time. As long as the error fails to reach zero, R K I ∗ e ( t ) dt will adjust itself to compensate for the continued error. As with the derivative, the integral value is not B-Term 2023-24—Prof. Markus P. Nemitz

11 RBE 2002: Unified Robotics II—Lab 1: velocity control available directly, but must be estimated from discrete samples. In this case, the integral can be estimated using a summation that adds the current error value at each time step: Z t 0 e ( t ) dt ≈ t X i =0 e i ∗ ∆ t The algorithm above illustrates a complete PID controller. With an appropriate value of K I , the resulting controller reliably moves the car to the goal regardless of the slope. def pid_controller (x , r , K_P, K_I, K_D ): e_prev = r - x e_sum = 0 #accumulator for integral term while True : e = r - x e_sum = e_sum + e de = (e - e_prev) u = K_P*e + K_I*e_sum + K_D*de car.throttle(u) e_prev = e B-Term 2023-24—Prof. Markus P. Nemitz

RBE 2002: Unified Robotics II—Lab 1: velocity control 12 2 Pre-lab This is an individual assignment. 1. (0.7 pts.) Describe the technology behind the encoders on your Romi. What physics are they based on (e.g., light or magnetism or something else)? How are they wired (encoder to micro- controller)? Draw a schematic! 2. (0.7 pts.) How many encoder counts equate to a full wheel revolution (360 deg.)? How many times does the magnetic disk rotate during a full wheel revolution? 3. (0.7 pts.) Write down the equation that converts counts into tangential velocity of the wheel. Explain the equation. 4. (0.6 pts.) What is pulse-width-modulation (PWM)? Draw diagrams that indicate 25%, 50% and 75% duty cycles. 5. (0.7 pts.) Write down the continuous equation u ( e ( t )) for a PI controller. Convert the equation into its discrete form using pseudo code. 2 2 Pseudo code refers to plain language description of steps in an algorithm. Examples B-Term 2023-24—Prof. Markus P. Nemitz

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

13 RBE 2002: Unified Robotics II—Lab 1: velocity control 3 Post-lab This is a group assignment. Submit one copy per group (but note that you will have data from each team member). 1. (0.5 pts.) Draw a block diagram of your velocity controller (one diagram per group). Use the terminology that was introduced in lecture and pre-lab. 2. (0.75 pts.) Create plots of speed over time for each motor (left and right), applying an effort of 100 for 10 seconds (chassis.StartDriving(100, 100, 10000)). Calculate the average and standard deviation of your speeds for the left and right motors. Each member of a group has to create their unique plots and calculations. 3. (0.75 pts.) Set K P = 0 . 3 and K I = 0 . Create plots of (i) speed over time, (ii) effort over time, and (iii) error over time, for each wheel, setting a velocity of 50 mm s for 10 seconds. Each member of a group has to create their unique plots. Why does the system not reach the target velocity (one answer per group)? 4. (0.75 pts.) Set K P = 10 and K I = 0 . Create plots of (i) speed over time, (ii) effort over time, and (iii) error over time, for each wheel, setting a velocity of 50 mm s for 5 seconds. Each member of a group has to create their unique plots. Why does the system oscillate (one answer per group)? 5. (0.75 pts.) Create plots of (i) speed over time, (ii) effort over time, and (iii) error over time, for each wheel, setting a velocity of 50 mm s for 10 seconds, using your PI-controller ( K P = 0 . 3 , K I = 0 . 1 ); if those values do not work (they work for my Romi), please change them as appro- priate for your robot system. Disturb the system by blocking a wheel (gently by pushing your finger onto the wheel) at 5 seconds (not for 5 seconds) and let it subsequently recover. Each member of a group has to create their unique plots. As a group, explain your plots by reasoning about velocity, effort, and error over time before and after you disturbed your system. 6. (0.5 pts.) Set the speed of your robot to either 1 inch s or 10 mm s . Using your PI-controller, drive your robot for 2,4,6,8, and 10 seconds ( detach your Romi from the USB cable ). Does your robot stop at the correct distances (use a ruler for verification)? SA sign-off: each group member, demonstrate your robot driving for 10 seconds and ending at the correct distance. 7. (0.5 pts.) Assuming that the left wheel stands still, how many counts does the right wheel have to turn so that the robot ends in a (i) π (ii) π 2 , (iii) π 4 rad. orientation? 8. (0.5 pts.) Assume that one of your motors is slower than the other when set to the same effort level (motors.setEfforts(L,R=L)).(Your Romi accidentally fell on the ﬂoor.) Explain how your PI controller could compensate for that and allow your robot to move straight still. B-Term 2023-24—Prof. Markus P. Nemitz

RBE 2002: Unified Robotics II—Lab 1: velocity control 14 4 Lab 1: velocity control In this lab, you and your group will program velocity controllers. First, you will have to convert your encoder counts into a tangential velocity. Second, you have to program a PI controller that regu- lates the motor effort based on tangential velocity. Third, you will create plots and analyze your data. Please place your robot on a coffee mug (or similiar) when programming, so you do not acci- dentally rip off the USB connector from your control board (control board cost: $50). 1. Download/clone lab1-velocity-control from github . Open the project in Microsoft Visual Studio using the Platform IO plugin. You can use other IDEs, but note that this code was written and tested by Professor Lewin and myself using MS Visual Studio. 2. Spend some time understanding the code. Much of the functionality is provided, but I want you to use this code as an example of how to code . Remember, understanding often means starring for extended periods of time at (here) a snippet of code. 3. Assignment 1: Finish programming the functions SpeedRight() and SpeedLeft() in chassis.cpp . These functions must return a velocity in mm s or inch s . Revise the lecture material if you forgot the counts-to-velocity equation. chassis.h contains constants that you can use to implement the counts-to-velocity equation. MotorControl() updates counts at interval = 50 ms . Use count_left, count_right and prev_count_left, prev_count_right to implement the counts-to- velocity equation. Note that SpeedRight() and SpeedLeft() return values of datatype ﬂoat . 4. Assignment 2: Finish programming the function UpdateEffortDriveWheelsPI() in chassis.cpp . Revise the lecture and pre-lab materials to derive a discrete implementation of a PI controller. Arguments target_speed_left and target_speed_right inform the controller about the set-point (revise lecture notes in case you do not know about these terms). The controller outputs an effort as function of error, whereas the error is the difference between target_speed_left and SpeedLeft() , target_speed_right and SpeedRight() , respectively. 5. Assignment 3: Use the SerialPlotter() function to output data to the terminal. The robot is programmed to execute your code for 10 s , starting with a press of button A. Once your 10 seconds recording is over, you can copy-paste the terminal output into Microsoft Excel and visualize your data. Familiarize yourself with the post-lab to create the plots that are required to pass this assignment. B-Term 2023-24—Prof. Markus P. Nemitz