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

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

Your preview ends here

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