MIE444 Mechatronics Lab 1

pdf

School

University of Toronto *

*We aren’t endorsed by this school

Course

444

Subject

Mechanical Engineering

Date

Apr 3, 2024

Type

pdf

Pages

Uploaded by momo_09

Mechatronics Principles LAB 1 – SimMeR: Robot Simulator I. BENNETT AND S. COLIC DEPARTMENT OF MECHANICAL AND INDUSTRIAL ENGINEERING UNIVERSITY OF TORONTO Lab v1.0 – SimMeR v1.0 © University of Toronto 2023 I. BENNETT AND S. COLIC | SEPTEMBER 2023

Lab 1: Robot Simulation The purpose of this lab is to instruct you on the use of the Simulator for Mechatronics Robots (SimMeR), whose code is located at https://github.com/ian612/simmer-python . It will help you gain an understanding of why it’ s important to simulate your robot designs prior to physically building them, and how to do this via the use of SimMeR. The lab consists of a Background and Theory section, Step-by-Step Walkthrough section, followed by Tasks to be completed without instructions. The completion of this lab requires you to complete all the Tasks . Questions that require answering are highlighted in grey boxes, and labelled with Q . Q Example Task Box: ➢ Download and install Python and the shapely, pygame, and numpy packages ➢ Install VS Code and extensions (or another development program of your choice) ➢ Create a github account and fork the SimMeR repository ➢ Download SimMeR and run the test client, verifying that it works Lab Preparation Each lab will have a page of requirements that need to be completed by the start of the lab. Before the start of each lab there will be a short quiz to test that you have read through the manual and have a reasonable understanding of what the lab is about. You will receive a grade of 0 if you do not complete the lab quiz by the submission deadline. The following tasks are required to be completed prior to the lab: 1. Read over the lab background notes. 2. Download and install SimMeR and all prerequisite toolboxes. 3. Read over the practical section of the lab manual. 4. Complete the pre-lab quiz on Quercus before the start of the lab.

Section A: Background and Theory This section of the lab introduces the simulator, how it works, what it can do, and what its limitations are. It is assumed that you have a basic knowledge of the Python programming language. Some core concepts will be reviewed in this section, but you may have to search online for further explanation. You can start with some of the resources listed under Resources at the end of this section. Part 1: Download and Installation of Software Packages All software used in this lab is freely available and open source. As such, it can be used on the computers provided in the MIE402 lab or on your own personal computer without any license requirements. Before reading the remainder of the background section, it is recommended (but not required) that you install Python, the required packages, and the VS Code development environment on your personal computer by following the steps in this section. This will make understanding and modifying the simulator code easier when it becomes necessary in the later stages of the lab. Instructions will be provided for both Windows and Mac operating systems. For any step that is OS-specific, the  icon will be used to denote Windows, while 🍏 will be used to denote Mac. Download and install Python 3.11 If you already have Python 3.11 or higher installed on your computer, you may skip this step (note that lower versions of Python 3 MAY work, but they are not guaranteed to). 1. Visit https://www.python.org/downloads/ and download the latest version for your operating system. This should be 3.XX.YY where XX is the major revision number and should be 11 or higher, and YY is the minor revision number. Make sure that you are installing a 64-bit version of the software (for  it should have amd64 in the installer filename, all 🍏 installers are 64-bit). Figure 1: Python download website

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

2. Open the downloaded installation file and follow the instructions to complete the setup. If you already have Python installed, you will be prompted to upgrade rather than install from scratch. You may need to restart your computer after this step, but likely won’t. a. If an option is given to you to add Python to your system’s path , make sure to do so. 3. Verify that Python installed correctly by opening a  Command Prompt or 🍏 Terminal window and typing python or python3 and pressing Enter. a. You should see text such as that shown in Figure 2 indicating that the Python environment is active. Figure 2: Python 3.11 environment b. Press Ctrl + Z (  ) or Cmd + Z ( 🍏 ) and Enter to exit the python environment 4. Install the required packages for SimMeR to function correctly. These can be done most easily from the command line. Assuming you added Python to your system path when installing, you should be able to type the following commands in any directory. Depending on your installation, you may have to type pip OR pip3 in order for these commands to work. a. pip install numpy OR pip3 install numpy b. pip install shapely OR pip3 install shapely c. pip install pygame OR pip3 install pygame Download and install git, VS Code, and extensions To use the simulator and edit the code, it is beneficial (though not required) to use an Integrated Development Environment (IDE) along with the version control software git. This will help with syntax-related highlighting for interpreting code, autocompletion, version control, and debugging. For MIE 444, the recommended IDE is Visual Studio Code (VS Code), which is developed by Microsoft and available for Windows, Mac, and Linux. Before installing VS Code you may wish to install the git version control system to help you manage the various versions of the control code you will write during the course of this course, though it is not required. Instructions for installing git are given below. • Download and install git by clicking the appropriate link for your OS on https://git- scm.com/downloads/ • Run the downloaded file to install git. To install VS Code, follow these instructions.

• Download and install Visual Studio Code from https://code.visualstudio.com/Download . Clicking the large button under your OS should auto-detect the correct version and download it. Figure 3: VS Code download website • Run the downloaded file, following the instructions to install the program. Make sure that the lines “Register Code as an editor for supported file types” and “Add to PATH” are checked if the options are available. • Open VS Code and look on the left side of the screen for the button shown in Figure 4. This will open the Extensions tab. Figure 4: VS Code extensions tab

• Using the Search Bar, search for and install the following extensions. The most recent version should be used. These extensions are recommended, but if you ever find any of these detrimental to your editing experience, you can disable or uninstall any of them without affecting the sim ulator’s functionality . a. Python Extension Pack i. Contains Python, autoDocstring, Jinja, Django, Intellicode, Python Indent, and Python Environment Manager Figure 5: Python Extension Pack information b. Pylint Figure 6: Pylint extension information c. Pylance Figure 7: Pylance extension information

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

d. isort Figure 8: isort extension information e. Github Pull Requests and Issues Figure 9: GitHub Pull Requests and Issues extension information Cloning the SimMeR code repository To access the simulator, a local copy of the SimMeR code must be made in a folder on your computer. To download it, visit https://github.com/ian612/simmer-python and look for the Releases field on the right sidebar. Find the latest version, and click on the Source code (zip) link to download the source code.

Figure 10: SimMeR github page and releases location Figure 11: Where to download the SimMeR source code Extract the zip file to a location on your computer where you wish to save it. It is suggested that you create a separate folder for storing control code (or any other code provided or created by you in the future) , and don’t store it within the simmer -python folder, but if you do wish to store them in the same place you can use the scripts folder.

Now open VS Code and click on the Source Control tab. Click Open Folder and open the folder where you extracted the SimMeR source code. You can add additional folders to the workspace by clicking File -> Add Folder to Workspace, and choosing the folder you wish to add. Figure 12: VS Code source control tab You should now see something similar to the following folder structure, where simmer-python is the folder where the SimMeR code is stored. You may also have another folder, in this case labeled MIE444 – Summer & Fall 2023 , for storing control scripts. Figure 13: Adding a second folder to the SimMeR workspace Once you have completed these steps, it is suggested that you save your workspace such that you can easily find and open it again without having to worry about losing your settings. To do so,

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

click File - > Save Workspace As… , and save it in your preferred location. It is suggested that you save the file within the folder you just created for the SimMeR code. NOTE: File paths saved as part of a VS Code workspace are stored relative to the workspace file. If you ever move your workspace file to a new location relative to the code folders, you will have to add them back to the workspace. Testing that SimMeR works The best way to run SimMeR is directly through VS Code, as this will give you access to convenient debugging tools. To run and debug a Python file in VS Code’s integrated terminal, you will have to tell VS Code what language you are using and where its interpreter is located. You can do this by clicking on the buttons shown in the bottom right corner of the VS Code window, making sure that Python is selected and that the interpreter path is set to the version of Python you want to use. Figure 14: VS Code interpreter setting location Once these steps are complete, you can simply press the F5 key or select Run-> Start Debugging in the top menu bar to run the file. If Python has been installed correctly and the interpreter is selected, you may have a set of options drop down from the top search bar asking what you wish to do. Simply select “ Python File Debug the currently active Python file” to run th e selected script. SimMeR contains a launch.json file within the .vscode folder that indicates that the main simmer.py file should be run when debugging is started rather than the currently open file. This is a quality of life feature so that you don’t ha ve to constantly switch back and forth between files in the editor to test your code. If you wish to disable this functionality, you can delete or temporarily rename the launch.json file.

SimMeR Program Structure This section describes the overall structure of the SimMeR program. SimMeR is made up of objects, each defined by a Python class and a set of parameters that are passed to it upon instantiation. The diagram in Figure 15 shows the structure, with the addressable objects in simmer.py shown as bubbles with darker backgrounds. Figure 15: SimMeR program structure chart Control Code This script is your code that you will write to control both the physical robot you build, and in the simulator. This should include your code for commanding the robot and interpreting its responses within the maze (and any other code that you write or is provided to you in the course). It should be able to send and receive commands and data from either a TCP socket (for the simulator) or over a COM port (for a bluetooth connection to a physical robot). You can write this script in any language you choose, but Python is recommended. SimMeR This is the main program file ( simmer.py ). It contains the code to instantiate all the objects that make up the Simulated Environment and Interface, interface with the keyboard and external control scripts, and run the simulation loop. You should never have to modify this file. Interface The Interface consists of the classes and objects that interact with the operator. You should never need to modify any of these files . Communication [COMM] The communication object ( communication.py ) manages the transmit and receive sockets for accepting commands and sending responses to and from the control script. The communication Control Code SimMeR Interface Communication [COMM] Transmit Buffer Receive Buffer Heads-Up Display [HUD] Display screen [canvas] Configuration File Simulated Environment Robot object [ROBOT] Devices (sensors) Devices (drives) Devices (motors) Maze object [MAZE] Block object [BLOCK]

object has two buffers where messages are stored after being received and before being transmitted. These buffers are checked and acted upon once per frame when the simulator is running. You should never have to modify this file. Heads-Up Display [HUD] The Heads-Up Display object ( hud.py ) gives visual indicators of the status of the simulator. In the top-left corner, the uppermost box flashes once per second (also called the heartbeat indicator). If you notice it is flashing at a rate lower than this, you may have to adjust downward the frame rate in the configuration file. The other six boxes indicate if any of the Q, W, E, A, S, or D keys are being pressed. These keys move the robot manually. You may want to do this if the robot gets stuck, or to manually reposition it in case of a glitch. This movement doesn’t activate any odometers on robot motor devices, but rotations are still recorded on gyroscope sensors. You should never have to modify this file. Figure 16: SimMeR display screen, or canvas Display Screen [canvas] The display screen shows the maze walls (red lines), floor pattern (black and white squares), and the robot, as well as any devices that are intended to be visible. Certain measurements will also be displayed here if enabled (i.e. the vision of an ultrasonic sensor, etc.). The canvas grid/orientation is such that (0, 0) is at the top left corner of the screen. Right is the positive-x (X+) direction, while downward is the positive-y (Y+) direction. Positive rotations are clockwise, while negative rotations are counter-clockwise. Simulated Environment The simulated environment is an abstraction of the physical environment that the robot will be in while navigating the maze. A visual representation of the environment is shown on the display

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

screen. There are 3 objects that make up the environment. You should n’t have to modify these files but may wish to alter or enhance functionality. Block Object [BLOCK] The Block object ( block.py ) represents the target block that your robot will need to navigate to and pick up. Maze Object [MAZE] The Maze object ( maze.py ) has two parts to itself, the walls and the floor pattern. The walls are defined as line segments, while the floor tiles are defined as both Shapely MultiPolygons and as pygame rect objects. It also contains functions needed to set up the maze walls and generate the floor pattern. Robot Object [ROBOT] The Robot object ( robot.py ) stores variables related to the robot, such as its size, outline perimeter, and position/orientation. It also contains several methods (functions) that do things such as update the position of the robot, parse commands, activate devices, check collisions with maze walls, etc. Device Objects Device objects (files in the devices folder) represent devices that are stored on the robot. These each have a position and orientation relative to the center of the robot, which is fixed once the simulation starts. They each individually store data and have methods (functions) specific to the functionality of that device and are defined by several parameters which are specified in the configuration file and passed to the device as it is initialized by means of a python dictionary. In addition to an initialization method ( __init__ ), each device must contain a method called simulate() that indicates what the device does if a command is sent to it. The structure of this function is below and will always be passed a floating-point value (or 0 if one was not included), and a copy of the current environment ( BLOCK , MAZE , and ROBOT ). Each device may also contain an optional update() method that defines something to do on each frame of the simulation. This can be used for sensors such as gyroscopes that may drift over time. The structure of this function is shown below, where environment has the same structure as in simulate() . Each device also has a type, stored as the variable d_type in the object, that is either drive , sensor , or motor . Specific device types will be discussed in more detail in their own section. You shouldn’t have to modify these files but may wish to add new ones.

Configuration File [CONFIG] The Configuration file ( config.py ) is the main file that you will be modifying to define the simulation parameters for the maze, the block, the robot, and the robot’s devices. It also contains several settings related to the graphical display of the simulation. Most settings in the configuration file include comments describing their function. Control Flags • rand_error – If False , uses the seed specified by floor_seed in the Maze Definition Information section. If True , uses a random error seed. It is recommended to always leave this set to False . • rand_bias – If True , uses randomized drive biases rather than hardcoded ones specified in device settings. If False , the hardcoded values are used. This allows for testing robustness of control algorithms against biases in the drive system. This setting does nothing in SimMeR version 1.0 but will be implemented in future revisions. • bias_strength – These values determine the intensity of the drive bias if rand_bias is set to True. This setting does nothing in SimMeR version 1.0 but will be implemented in future revisions. Network Configuration for Sockets • host – The IP address of the computer running the control script, in string format. You will almost always be running this script and SimMeR on the same computer, so the localhost address of ‘ 127.0.0.1 ’ can be used. • port_rx – The port on which SimMeR will receive messages from the control script. This should be a 5-digit number, and should be mirrored in the control script (i.e. the control script’s transmit port should be the same as this number). • port_tx – The port on which SimMeR will transmit messages to the control script. This should be a 5-digit number, and should be mirrored in the control script (i.e. the control script’s receive port should be the same as this number). • timeout – The time (in seconds) for the transmit and receive sockets. • str_encoding – The string encoding for messages received over the communication sockets from the control script. Block Information • block_position – A two-element list defining the position of the center of the block on the grid in [x,y] format, where x and y are the grid positions in inches. • block_rotation – The rotation of the block in degrees from the +Y direction (downward on the canvas). • block_size – The size of the block in inches. It is assumed that the block is a cube and has equal width, length, and height side lengths. Robot Information • robot_start_position – A list containing the robot’s starting [x,y] coordinates.

• robot_start_rotation – The starting rotation of the robot, in degrees from the +Y axis. • robot_width – Width of the robot, in inches. This is only used to determine the outline and is not needed if you define an outline other than the default square one. • robot_height – Height of the robot, in inches. This should be the maximum height of the robot if the top of the robot is not level. • robot_outline – A list of pygame.math.Vector2 objects that define the robot’s perimeter. These points should be defined as (x, y) coordinates relative to the centroid (rotation point) of the robot. The units are in inches. Maze Definition Information • wall_segment_length – Length of each maze wall segment in inches. • floor_segment_length – Side length of each floor pattern square in inches. • walls – A matrix (list within list) used to define the size of the maze and define where the walls are located. The first row represents the top “row” of the maze where wall segments should be located. 0’s represent locations blocked by walls, while any other value represents an open floor space that the robot may move through. 1’s represent normal spaces, 2’s represent locations where the block may be placed, and 3’s represent locations where the robot may be started/block drop off locations. In SimMeR version 1.0, there is no mechanical difference between 1, 2, and 3. • floor_seed – The randomization seed used to generate the floor pattern using the Mersenne Twister algorithm (and subsequently, error measurements). This value should be 5489 to generate the correct pattern. Graphics Information • frame_rate – The target simulator frame rate in Hz. If you notice the heartbeat indicator is flashing at a rate of less than once per second, you can reduce this value from its default of 60, though the accuracy will not be affected if the simulator runs more slowly. It is recommended that you choose an integer value that your computer screen’s refresh rate is divisible by (most monitors run at 60 Hz, so 30, 20, 15, etc. would be valid). This value does increase the distance that the robot moves each frame, so values that are too low may lead to inaccurate collision detection for fast drive speeds. • ppi – Stands for Pixels Per Inch. One inch in the simulator should have a length of this many pixels. The default is 16, which should allow the entire maze to be seen on a 1080p screen. If your screen has a higher or lower resolution, you may want to adjust this up or down to make the simulator easier to see. Changing this value will not affect the accuracy of the simulator. • border_pixels – The width of the screen border surrounding the maze area, in pixels. • background_color – The color of the background of the simulator, in (R,G,B) tuple format. Each value should be an integer between 0 and 255 (inclusive). • wall_thickness – The thickness (in inches) to draw the wall segments on screen. This does not influence collision and measurement results.

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

• wall_color – The color to draw the wall segments on screen, in (R,G,B) tuple format. Each value should be an integer between 0 and 255 (inclusive). • robot_thickness , block_thickness – Same as wall_thickness , but for the robot & block outlines, respectively. • robot_color , block_color – Same as wall_color , but for the robot & block outlines, respectively. Device Configuration More details on device configuration settings are provided in the following section, but these three settings MUST be present in the config file, or the program will crash. • motors – A dictionary that instantiates and stores the motor devices to be added to the robot. This must be instantiated before drives is defined. The dictionary can be empty if no motors are present. • drives – A dictionary that instantiates and stores the drives devices to be added to the robot. This must be instantiated after drives . The dictionary can be empty if no drives are present. • sensors – A dictionary that instantiates the robot’s sensor devices. This can be de fined before or after motors and drives . The dictionary can be empty if no sensors are present. SimMeR Devices SimMeR devices are objects that represent a part of your robot that performs a specific task or function. Each motor, drive, and sensor is a device; if your robot doesn’t have any de vices defined, it cannot do anything. Each device is instantiated with a two-character id string that is used to identify it. This can be any two ASCII characters other than ‘xx’ , though it is recommended to use simple alphanumeric characters. Programmatically devices are first set up with the Device() super class, which contains definitions and methods that are important for all devices, regardless of type. This sets data like the device’s identification, type, relative and global positions, and display properties. The Device() super class also includes functions for updating the device ’s position & outline, and for drawing itself on the canvas. The device’s sub class is specific to that type of device and contains device-specific data and methods. All device sub classes must contain an __init__() method and a simulate() method. Even if the simulate() method does nothing, an empty method must be included with a pass or return None statement. Simulating a device (calling its simulate() method) can be performed by sending a command to the communication object containing the device’s two -character identifier and listening for its response. All devices must respond with an 8-byte double precision floating point number, the precise meaning of which changes depending on the device. Defining device parameters in the config.py file There are two steps to creating devices in SimMeR. The first is defining the device’s parameters, and the second is instantiating it (i.e. creating an instance of it) in the appropriate dictionary.

Device types and sub classes Devices are broken down into 3 types: motors, drives, and sensors. Each of these types has at least one sub class associated with it that defines its devices, whose python files you can find in the folder devices . A chart of the devices included with SimMeR by default is shown below. Figure 17: Device type and subclass chart MotorSimple objects define motors and wheels that will be used to move the robot around the maze. They are relatively simple, and each also contains an odometer to track how far the wheel has moved since the start of the simulation. The odometers in the simulator are abstract, and track the amount of linear movement the wheel’s outer edge has moved, no t the number of rotations as an odometer on a real wheel might. Drive objects are abstract devices and are used for commanding the robot to move. On a real robot, the drive is just microcontroller code that commands the appropriate wheels to move in an appropriate manner when a direction is selected. Each movement direction should have its own drive device. For example, a two-wheeled robot may have one drive device for forward/backward, and one for rotation. A robot with four omni-wheels may also add another drive for left/right “strafing” movement. A robot with mecanum wheels may also include additional drives for diagonal movement directions. Sensor objects are devices that are intended to gather information from the environment that can be passed back to the control code. These devices generally have a single purpose. Defining a device Device objects are defined by parameters stored as python dictionaries, where each parameter has a key and a value . The key is the parameter’s name by which it can be referenced, and the value is the actual value of the parameter, be it a number, string, list or other object. These dictionaries are read and parsed by the device’s sub class when it is instantiated. To see an example, you can check the sample config.py file included with the SimMeR source code. Device (super class) motor (type) MotorSimple (sub class) drive (type) Drive (sub class) sensor (type) Compass (sub class) Gyroscope (sub class) Infrared (sub class) Ultrasonic (sub class)

All devices have four required parameters, which, if not included, will cause the simulator to crash: • id – A two-character string that provides a unique identifier for the device. • position – A two-element list that indicates the [x,y] position of the device relative to the center of the robot. • rotation – A floating point number or integer that gives the rotation of the device in degrees off the robot’s + Y axis. • visible – A Boolean ( True / False ) value indicating whether the device should be drawn on the canvas. Each sub class also has a set of parameters that are specific to it that can optionally be specified. The sub classes are written such that if these are not included in the parameter dictionary, a default value will be used instead. As an example, the initialization code for the ultrasonic sensor is shown in Figure 18 below. Graphical and positioning properties such as the outline, height, color, and whether the measurement is visible are included, as are simulation parameters such as the beamwidth, number of rays to test, and error percentage values.

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

Figure 18: Ultrasonic sensor sub class initialization function Sensor sub classes are generally written such that if none of these optional parameters are specified in the parameter dictionary, the default values will result in a functional sensor. Just because a sensor is functional, though, does not necessarily mean that it will function in exactly the way you want it to. Drive specifics The Drive sub class is different from motors and sensors in that it has additional required parameters that, if not specified, will cause the simulator to crash. • ‘ motors ’ – This is a list of the motor devices that will be active when this drive is activated. This list must contain devices that have been instantiated in the motors dictionary. DO NOT instantiate new motor devices here. An example is shown in Figure 19. Motors are instantiated in the motors dictionary, but the drive parameters dictionary w0_info contains a parameter called ‘motors’ that includes the two motors in a list.

• ‘ motor_direction ’ – A list the same length as the ’m otors ’ that specifies whether each motor is moving forward or backward (+/-1) when the drive is active. Figure 19: Motor instantiation and drive parameter definition You must also specify ONE of the following two parameters: • velocity – A two-element list that defines the speed and direction of a robot’s movement. The list is of the form [x,y] , and indicates speed in inches/second. For drives defining rotation, this parameter’s value must be [0,0] or not defined. • ang_velocity – Defines an angular velocity that the drive will rotate the robot at, in degrees/second. For drives defining translational movement , this parameter’s value must be 0 or not defined. The error and bias terms are more complicated for drives than sensors. Using the example of the above drive w0_info you can see that each of them is a dictionary defining an x , y , and rotation term, as opposed to sensors, which only have one value for each of error and bias . These values indicate movement and rotation bias and error in the direction specified, where 0 is no error/bias. In the example shown, the drive’s velocity indicates that it will move the robot in the +Y direction when called, but there will be some random error in the x and y directions, as well as in the rotation axis. There will only be a constant bias in the rotation axis. Instantiating a robot’s de vices Once a devic e’s para meters have been defined, it must be instantiated (i.e. an instance of it must be created). Instantiation is relatively simple compared to choosing device parameters. To do so the appropriate sub class must be called with the parameter dictionary as an argument within a dictionary named according to the device’s type. An example of sensor instantiation is shown below in Figure 20.

Figure 20: sensors instantiation example The dictionary is called sensors , and each device has a key which is equal to it’s two-character device ID string, and a value where the appropriate sub class is called with the parameter dictionary as an argument. The recommended order for defining devices and instantiating them is: 1. Define all motor s’ parameters 2. Instantiate motors 3. Define all drives’ parameters 4. Instantiate drives 5. Define all sensors’ parameters 6. Instantiate sensors With the devices instantiated properly in the configuration file, the Robot will automatically detect them when it itself is instantiated, and they will be added to it. Included devices There are six sub classes included in SimMeR that define devices. • motor o MotorSimple • drive o Drive • sensor o Ultrasonic o Gyroscope o Compass o Infrared MotorSimple The MotorSimple subclass is located in motors.py and defines a wheel/motor combination. The direction, position, and orientation are important as, when a drive is called, they are each factored in when determining how far the wheel’s has moved as part of the drive command, and

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

therefore the value stored on the motor’s odometer . Its output, when the simulate() method is called, is the distance the wheel has travelled as a floating point number. Drive The Drive sub class is located in drive.py and is an ab stract device that defines a robot’s movement in one direction or a rotation about its centroid. Each drive device should only define translational OR rotational movement, never both. To call a drive, its device id must be followed by a hyphen and a string indicating a number. For translational drives, this is the distance to move in inches. For rotational drives, it is the number of degrees to rotate. Some example strings are shown below, where ‘w0’ is a drive that moves forward, and ‘r0’ is a rotational drive. • Move forward 5 inches w0-5 • Move backward 5 inches w0--5 • Move backward 3.57 inches w0--3.57 • Rotate clockwise 20 degrees r0-20 • Rotate counter-clockwise 270 degrees r0--270 Once a drive command has been received and acknowledged, the robot will respond with a floating point inf (infinity). If a robot receives a drive command while it is still in the process of executing a previously issued drive command, it will return a floating point nan (not a number). To stop all drive actions, a command can be sent to device ’x x ’ . • Stop all drives (emergency stop) xx Ultrasonic This sensor is used to detect distance between itself and the walls of the maze or the block. It has an effective beamwidth cone within which it will detect objects. Within the cone, several rays are tested each time the sensor is called, and the shortest one is returned as the distance the sensor measures. Ultrasonic sensors placed at different heights may or may not detect the target block, depending on the distance to the block and its size. Its output will include some percent error specified as by the error parameter. Gyroscope This sensor continuously updates based on the rotation of the robot to give an estimate of direction. It is an integrative sensor and as such it will drift over time regardless of whether the robot is moving or not. A constant drift can be defined by the bias parameter. When called, it will return the angle between its current and starting orientations in degrees.

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

Compass This sensor takes an instantaneous measurement of the current absolute orientation, and returns it with some error, to simulate lack of precision. This error can be defined by the error parameter. When called, it returns the angle between the robot’s current orientation and the +Y axis. Infrared The downward-facing IR sensor is intended to detect the floor pattern of the maze . The sensor’s height and field of view (definable in device parameters) determine a circular area on the floor that the sensor can “see”. The area within that circle that is white is calculated, error is added, and the percentage of coverage is compared to a percentage threshold defined by the user in the device parameters. When called, this device will return a 1 if the sensor detects a white tile below it, and a 0 if it detects a black tile. Making your own devices There are six included devices in SimMeR, but you may wish to create your own to replicate other types of sensors or motors. To do so you should follow the following steps: 1. Create a new python file in the devices folder within SimMeR. This is where you’ll define the sub class. Name it something appropriate. You can also copy the template.py file and rename it. 2. Within that file, set the name of the sub class to be something appropriate. In the template file, this is Template . Note that capitalization is important. 3. Set up your device to act as you want it to by using the __init__() , simulate() , and update() methods. Make sure you DO NOT change the arguments for these functions from those in the template file. You can create other methods as well if you wish that can be called in one of these 3 primary methods. 4. Set the configuration file to import your new device so it can be used. In config.py at the bottom of the list of imports add the following line, replacing template and Template with your file and sub class names, respectively. ➢ from devices.template import Template With these steps completed, you should now be able to define and instantiate the device at the appropriate place in the configuration file depending on whether it is a motor, drive, or sensor. Resources This section contains further resources to help you with understanding the python programming language. You do not need to do anything with these sites to complete the lab, they are just provided as helpful reference material. 1. Beginner ’s guide to Python a. https://wiki.python.org/moin/BeginnersGuide 2. Beginner’s guide for non -programmers a. https://wiki.python.org/moin/BeginnersGuide/NonProgrammers

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

3. Object-Oriented programming in Python a. https://realpython.com/python3-object-oriented-programming/ b. https://www.geeksforgeeks.org/python-oops-concepts/

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

Section B: Lab Procedures In this part of the lab, you will be guided step-by-step through the process of using the robot simulator. F irst, you’ll configure a sample robot and guide it manually through the maze to a target. Then, you’ll do the same thing by manually controlling the robot via command strings. Third, you’ll add a new sensor type to the simulator. Finally, you’ll use the provided obstacle avoidance code to see how the controllability of the robot varies with sensor precision. PART 1: Configuring a Sample Robot In part 1, you’ll modify the configuration file of SimMeR to simulate a robot with the desired configuration. The robot design that we will be simulated is provided in Figure 21. Figure 21: Simple rover design. Unless specifically specified all dimensions are in inches. Requirements: • Computer with SimMer installed Procedure: 1. Ensure SimMeR has been downloaded and installed onto your computer before proceeding. 2. Go to the directory where SimMeR has been installed/placed, then open the file config.py . The configuration file is where we will be making all the adjustments to create a model of our simple rover design. 3. Set the outline of the rover to be equal to the code below.

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

robot_outline = [pm.Vector2(-2.875,-4), pm.Vector2(-2.875,2.75), pm.Vector2(-1.655,4), pm.Vector2(1.655,4), pm.Vector2(2.875,2.75), pm.Vector2(2.875,-4)] 4. Configure the two motors by assuming a wheel of 2-inch diameter and 0.5-inch depth, that is centered between the two lead screws. Normally you would have to calculate the centre position of the wheel, but for simplicity, we will provide you the positions. Based on this information, Motor 0 is at position [3.125,0] and Motor 1 is at position [-3.125,0] . Provided below is the updated code for the config.py file. ### DEVICE CONFIGURATION ### # Motors m0_info = { 'id': 'm0', 'position': [3.125, 0], 'rotation': 0, 'visible': True } m1_info = { 'id': 'm1', 'position': [-3.125, 0], 'rotation': 0, 'visible': True } motors = { 'm0': MotorSimple(m0_info), 'm1': MotorSimple(m1_info) } 5. Save your changes and run the simulator. You should see a bimodal drive system represented in the rover avatar. Verify that the positions you selected are correct. 6. Now we will configure the ultrasonic sensors. Similar to how we updated the motor configuration, update the position of the ultrasonic sensors, so that there are 4 sensors facing outwards, centred on each of the four sides. Ignore all the other sensors for now. Provided below is the updated code in the config.py file relating to the ultrasonic sensors. ### DEVICE CONFIGURATION ###

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

# Sensors u0_info = { 'id': 'u0', 'position': [0, 2.5], 'height': 1, 'rotation': 0, #'error': 0.02, 'outline': [ pm.Vector2(-1, -0.5), pm.Vector2(-1, 0.5), pm.Vector2(1, 0.5), pm.Vector2(1, -0.5) ], 'visible': True, 'visible_measurement': True } u1_info = { 'id': 'u1', 'position': [-2.5, 0], 'height': 1, 'rotation': -90, #'error': 0.02, 'outline': [ pm.Vector2(-1, -0.5), pm.Vector2(-1, 0.5), pm.Vector2(1, 0.5), pm.Vector2(1, -0.5) ], 'visible': True, 'visible_measurement': True } u2_info = { 'id': 'u2', 'position': [-2.5, 0], 'height': 1, 'rotation': 90, #'error': 0.02, 'outline': [ pm.Vector2(-1, -0.5), pm.Vector2(-1, 0.5), pm.Vector2(1, 0.5),

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

pm.Vector2(1, -0.5) ], 'visible': True, 'visible_measurement': True } u3_info = { 'id': 'u3', 'position': [0, -2.5], 'height': 1, 'rotation': 180, #'error': 0.02, 'outline': [ pm.Vector2(-1, -0.5), pm.Vector2(-1, 0.5), pm.Vector2(1, 0.5), pm.Vector2(1, -0.5) ], 'visible': True, 'visible_measurement': True } sensors = { 'u0': Ultrasonic(u0_info), 'u1': Ultrasonic(u1_info), 'u2': Ultrasonic(u2_info), 'u3': Ultrasonic(u3_info) } ### TESTING AND DEBUG SETTINGS ### simulate_list = ['u0', 'u1', 'u2', 'u3'] 7. Save your changes and run the simulator. You should now see the ultrasonic sensors you configured visible on the rover avatar. Furthermore, there should be rays pointing away from the sensors indicating what the sensor is able to detect. Verify that everything looks correct and makes sense. The final line in the above code forcibly simulates the ultrasonic sensors every frame. While it is useful for verifying that they are working correctly, it will slow down the simulator. Once you have verified all the simulators are working, comment out the highlighted line by adding a # to the beginning of it. 8. Incorporated in the simulator as a debugging feature is the ability to move the rover around using the “w”, “a”, “s”, “d”, “q”, and “e” keys on your keyboard. Use the keys to move the rover around the maze and make a note on how accurately the rover moves.

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

9. Much like playing an arcade game, controlling the rover with the keyboard may have a bit of a learning curve. Despite the challenges you may face controlling the rover manually, this is an unrealistically precise representation of how the rover would move. In the real world the motors will not drive perfectly straight, and we can model that by using drive commands to control the robot and adding some bias and noise to them. a. Note that using the keyboard to control the robot will always move it perfectly in the intended manner. The error and bias terms will only be accounted for when using drive commands to move the robot. 10. Modify the drive code to introduce bias error as shown in the code below. Note the highlighted code, that defines the bias. ### DEVICE CONFIGURATION ### # Drives w0_info = { 'id': 'w0', 'position': [0, 0], 'rotation': 0, 'visible': False, 'velocity': [0, 6], 'ang_velocity': 0, 'motors': [motors['m0'], motors['m1']], 'motor_direction': [1, 1], 'bias': {'x': 0, 'y': 0, 'rotation': 0.2} } r0_info = { 'id': 'r0', 'position': [0, 0], 'rotation': 0, 'visible': False, 'velocity': [0, 0], 'ang_velocity': 120, 'motors': [motors['m0'], motors['m1']], 'motor_direction': [1, -1], 'bias': {'x': 0, 'y': 0, 'rotation': 0.02} } drives = { 'w0': Drive(w0_info), 'r0': Drive(r0_info) }

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

11. To drive the rover using drive commands, run SimMeR and while it is running, in VS Code press the Split Terminal button shown below to open a second terminal window. Figure 22: Split terminal button location 12. Type the following commands in the second terminal to run the test script and move the rover. Comment on how the drive biases influence the movement of the robot. a. Type the following to initialize the test script. You may have to use python or python3 i. python scripts/test_client.py b. Type the following code into the terminal and press Enter to make the rover move forward 6 inches. i. w0-6 c. Type the following code into the terminal and press Enter to make the rover move backward 6 inches. i. w0--6 13. Close SimMeR and the test script by pressing Ctrl + C (  ) or Cmd + C ( 🍏 ). Modify the drive code as shown in the code below to introduce random error. Then start SimMeR and the test script and, using the commands from step 11, move the robot around the maze. ### DEVICE CONFIGURATION ### # Drives w0_info = { 'id': 'w0', 'position': [0, 0],

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

'rotation': 0, 'visible': False, 'velocity': [0, 6], 'ang_velocity': 0, 'motors': [motors['m0'], motors['m1']], 'motor_direction': [1, 1], 'bias': {'x': 0, 'y': 0, 'rotation': 0.2}, 'error': {'x': 0.02, 'y': 0.05, 'rotation': 1} } r0_info = { 'id': 'r0', 'position': [0, 0], 'rotation': 0, 'visible': False, 'velocity': [0, 0], 'ang_velocity': 120, 'motors': [motors['m0'], motors['m1']], 'motor_direction': [1, -1], 'bias': {'x': 0, 'y': 0, 'rotation': 0.01}, 'error': {'x': 0.003, 'y': 0.003, 'rotation': 0.02} } drives = { 'w0': Drive(w0_info), 'r0': Drive(r0_info) } Q : Comment on how the drive errors tested above could occur in real motors and drive system. 14. Play around with different error settings to get a good sense of how difficult it can be to control rover that has large drive errors.

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

Part 2: Creating Control Code Requirements: - Computer with SimMeR installed - Client test code – dead_reckoning.py Procedure: 1. At the conclusion of Part 1 you should have a configured rover drive system and four ultrasonic sensors. Go into the configuration file and remove any errors (including bias) in the motors and ultrasonic sensors by commenting out the lines where they are defined (don’t forget to remove trailing commas from the lines above if necessary) . We will be starting with a rover that drives perfectly and has perfect sensor readings. 2. Go into the scripts folder and open the dead_reckoning.py file. This file has all the code necessary to connect to a running simulation to initiate a sequence of movement and sensing commands that, under perfect drive conditions, will drive the rover from the starting location in the maze to the target block. 3. Run the simulator code to initiate the simulation. Then, separately run the dead_reckoning.py client test code (a.k.a. automated control sequence). If everything works as expected, you should see the simulation showing the rover traveling through the maze to get to the target block. 4. Next, we will explore the effects of bias on our drive system to see how robust the dead reckoning control code is at handling noise. Implement the same bias used in Part 1 of this lab by uncommenting the appropriate lines in the config file and then run the simulator and the client dead_rockoning.py code. Comment on how well the rover performs. Does the rover reach the target block this time? 5. Now remove the bias and introduce random error in the drive system and repeat the simulation. Comment on how well the rover performs and how it compares to the performance with bias error. Q : Come up with some suggestions on the different ways you could modify the dead_reckoning.py sample automated control to ensure the rover gets to the target block, despite some errors in the drive and sensors. 6. As the final step of this part of the lab we will modify the dead_rockoning.py client code to display sensor readings. Uncomment lines 91-102 to display the ultrasonic sensors ’ readings as the robot moves. Note that we leave a small amount of time between transmitting a command and listening for a response, so that the simulator has time to process and respond to it.

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. So far, the sample code has generated perfect sensor readings. Let us now introduce some error in the sensor readings to see how things change. Like we did with the drive system, we can add error to the ultrasonic sensors. Modify the sensor configuration code to introduce random error by uncommenting the error parameter in the sensor definitions in the config file. 8. Run SimMeR and the test_client.py script, and use them to drive the robot through the maze. Then try to do so while just using the sensor measurements rather than looking at the simulator display. Comment on the effect observed when you drive your rover. Q : Comment on how the ultrasonic errors observed by running the code above could occur in real ultrasonic sensors. 9. Play around with different error settings to get a good sense of how difficult it can be to control a rover that has large drive and sensor errors. Task 1: The following task can be skipped until the entire lab has been completed. Using any one of the drive noise settings introduced in Part 1 that leads to a collision, create a copy of the dead_reckoning.py code and update it so that it can stop the rover from hitting the obstacle whenever any of the sensors are 2” from an obstacle . You may have to slow the default velocity of the drives in order to get your code to work. Provide a short recording demonstrating that you were successfully able to stop before hitting an obstacle under noisy conditions. This will be required as part of the assignment submission. You can record a video of your screen by pressing Win + Alt + R (  ) or Shift + Cmd + 5 and selecting the Record button ( 🍏 ). Describe at least two distinct situations where the above collision avoidance code would fail. Task 2: The following task can be skipped until the entire lab has been completed. As a final task for this lab, you are asked to simulate the differences in time to drive the rover through the simulator from a predefined starting location specified in Part 2, to the loading zone, using manual and automated control, with bias and error set at 0. The two modes of operation that we will be tracking are the following: 1. MANUAL – using the simulator only, along with the debugging k eys (i.e., “a”, “w”, “s”, and “d”) , drive the rover from the starting position to the target block.

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

2. AUTOMATED – run the dead_reckoning.py client code to drive the rover from the starting point to the loading zone. Comment on the difference in performance using the two different modes of control. Which option is the fastest for controlling the rover through the maze? Which option would you pick if you wanted to win a race through the maze? The MANUAL control is not a true representation of the difficult task of navigating through the maze because you are relying on your eyes to make control decisions. Comment on how this would change if you only had access to the sensor readings. Consider how the different modes of operation would be affected if we introduced some errors in the drive and sensor readings. Provide a short recording or recordings comparing the MANUAL control through the maze with the AUTOMATED control through the maze. This video will be used as part of the lab assignment submission. Lab Deliverables At this point you should have completed Parts 1 and 2 of the lab. As part of the final deliverable you are asked to: 1. Answer the 1 Q in Part 1 and the 2 Q s in Part 2 2. Complete Tasks 1 and 2 at the end of Part 2 3. Complete a Quercus quiz (lab assignment) on the material covered in the lab by the specified due date

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

MIE444 Mechatronics Lab 1

Related Documents