Clawbotics Control Center:

Transcription

1 Clawbotics Control Center: Maintenance Report Jessel Serrano April 12th, 2015 CEN 4935 Senior Software Engineering Project Spring 2015 Instructor: Dr. Janusz Zalewski Software Engineering Program Florida Gulf Coast University Ft. Myers, FL

2 1. Introduction The Clawbotics Control Center focuses on tracking the location of the VEX Clawbot [2] (Figure 1) before and after manipulation, allowing the user to know exactly where the robot is and how far it has traveled. Using the VEX Network Adapter on the Clawbot, remote and wireless control is achieved. A website is implemented that features a panel to control the Clawbot via a network. Additionally, a network stream from the mounted IP camera is implemented to allow live video feed. By installing additional sensors onto the Clawbot, such as the Integrated Encoder Module as shown in Figure 2, the relative distance and angle to the starting location can be recorded with precision. These data are to be interpreted via client-side and then transformed into a graph to display the current position of the Clawbot as well as its starting position and path traveled. The importance of these concepts and respective technologies cannot be understated. Remote accessibility, manipulation, and tracking are quintessential tools for missile guidance, deep-sea and space exploration, automobile navigation and counter-theft, etc. While this is a classroom project with student robotic systems, one cannot underestimate the striking similarity between the Clawbotics Control Center and the Mars Exploration Rover. Figure 1: The VEX Clawbot Figure 2: The Integrated Encoder Module 2

3 1.1 Overview With the development of more advanced and autonomous robotic systems, the need for software to control these machines is becoming more prevalent. First and foremost, the goal of this sort of software is to establish a form of control over a physical system, possibly remotely. This task is accomplished in this project by a basic control system accessed through a website which allows minimal controls and a utility to upload new software to the Clawbot. The finished design is a web panel, accessible via vex.cs.fgcu.edu (Figure 3). Figure 3: Original VEX ClawBot Manager The control panel allows the controlling and tracking of the Clawbot. At present, there are a number of commands available, such as Forward, Turn, Stop, Lift/Drop and Open/Close Claw. Additionally, a user is able to track the location and movement of the Clawbot via the web-based control panel by utilizing the sensors attached to the physical system. Figure 4, which represents the Physical Diagram, shows the physical configuration of all entities involved. 3

4 Figure 4: Current ClawBot Physical Diagram A brief description of functions of all devices is given below: The VEX Microcontroller must be turned on before operation. The user logs in to the control panel and is presented with a visual display consisting of a video feed and control scheme. The camera, which is physically attached to the VEX robot chassis, wirelessly transmits the video feed to the control panel. The camera operates apart from the VEX Microcontroller and sends its data to the Web-Based Control Panel through its own hardware and wireless capabilities. Any controls the user inputs to the control panel are transferred wirelessly to the VEX Network Adapter, which then transmits the instructions to the microcontroller. The microcontroller transmits instructions and voltage control to the motors and servo to move the robot. The Integrated Motor Encoder [3] (known as the IME), attached to the robot s VEX 2- wire motor 393 drive motors, measures how fast the robot is going, what direction it is traveling in, and how far it has traveled. It sends this data to the microcontroller, which uses the VEX Network Adapter to transmit data to the Web Control Panel. The physical device is known as an Integrated Motor Encoder, while the respective software/firmware and functionality is known as the Integrated Encoder Module. The Web Control Panel uses the feedback data from the IME to create new instructions for the robot to follow and uses the VEX Network Adapter to transmit this data. The context diagram for the software is shown in Figure 5. In this diagram, the Clawbotics Control Center is shown as a combination of both a Web-based Control Panel and the VEX Clawbot Microcontroller. These two components communicate over a network. Each component has multiple devices attached. These devices send and receive signals to and from 4

5 either the control panel or the microcontroller. The devices, used by the Web-based Control Panel, are the keyboard and mouse, the visual display linked to the computer and a wireless camera that is physically attached to the Clawbot. The devices attached to the VEX microcontroller include two Integrated Motor Encoders (one for each motor), two drive motors and a claw servo. Figure 5: Current ClawBot Context Diagram 5

6 1.2 Requirements Specification In addition to the functionality described in previous sections, specific requirements placed on both major software components are outlined below. Additionally, a use case diagram in Figure 7 illustrates the robot operation from a user s standpoint. Figure 6: Use Case of C3 Software 1.2.1) Clawbot Microcontroller Software (CMS) ) Input Requirements a) The CMS shall take signals from the Integrated Motor Encoders b) The CMS shall receive instructions from the WCP through the network adapter module ) Output Requirements a) The CMS shall send On/Off signals to the drive motors to control their rotation b) The CMS shall send step signals to the claw servo to open and close the claw ) Functional Requirements a) The CMS shall use the data sent by the WCP to control the drive motors and claw servo b) The CMS shall use the data sent by the WCP to reprogram itself. 6

7 b) The CMS shall use the signals received by the Integrated Motor Encoders to determine its direction, distance and speed Web-based Control Panel (WCP) ) Input Requirements a) The WCP shall take keyboard/mouse inputs in the form of button clicks, strings and integers b) The WCP shall take visual data from the camera attached to the robot s chassis ) Output Requirements c) The WCP shall send data (navigational signals and code) to the CMS through a network d) The WCP shall send visual signals to a display ) Functional Requirements a) The WCP shall be displayed to the user in a web browser b) The WCP shall allow the user to control the drive motors and claw servo on the VEX Clawbot through a network in a web browser c) The WCP shall display a live video feed using data from the camera in a web browser d) The WCP shall display a Cartesian graph depicting the location of the VEX Clawbot and the path it has traveled in a web browser e) The WCP shall allow the user to upload his/her own code to the VEX Clawbot Microcontroller over a network Non-Functional Requirements ) Safety Requirements a) The CMS shall set the motor speeds to reasonable limits so as not to harm the environment or the Clawbot ) Security Requirements a) The WCP shall restrict access to the Clawbot controls to users who do not enter the correct login and password b) The WCP shall communicate with the CMS through a dedicated serial port. 7

8 1.3 Design Description Architectural Design The ClawBot Control Center (C3) software is composed of two parts: the Web-Based Control Panel (WCP) (Figure 7) and the VEX ClawBot Microcontroller Software (CMS) (Figure 8). The WCP is the processing portion of the system, receiving data sent from the microcontroller and turning it into both a visual display and additional instructions for the VEX ClawBot to follow. The CMS, located on the ClawBot itself receives data from sensors and uses instructions sent from the WCP to command motors and servos. The architecture design of the WCP is shown in Figure 7: Figure 7: Architectural Diagram of Web-Based Control Panel The WCP exists as a server on the Internet and is composed of: A Screen Handler to output visual data and create an IO system An I/O Handler to accept those key presses A processing unit to turn data received into usable instructions for the ClawBot software. 8

9 A Network Link to the Internet to both send those instructions to and receive sensor data from the ClawBot. The Web-based Control Panel combines these four components to create a coherent interface for the system. The CMS s architecture is shown in Figure 8. Figure 8: The Architectural Design of the VEX Clawbot Microcontroller Software The microcontroller is the hardware portion of the system which the WCP communicates to via the VEX Network Adapter attached to the ClawBot to allow wireless communication to the Internet. The microcontroller has multiple I/O ports for external devices. The CMS can handle sensors and motors attached via the I/O ports with an I/O Port Module. The data from sensors and instructions for the motors are transmitted to and from the WCP respectively, via the 9

10 Network Adapter Module. The operation of these two modules is coordinated by the Central Processing Module Detailed Design Since this software has two main parts, the control panel (WCP) and the microcontroller software (CMS), detailed designs are needed to describe the structure of each part. Figure 9 is a simple structure chart that demonstrates the interaction of the WCP modules, while Figure 10 displays the interaction within the CMS. Both diagrams represent a detailed view of the previous two figures (Figure 7 & 8). Each module is expanded to reveal the details of the respective software. The modules shown in Figure 9 and 10 that do not reveal inner modules are design elements that are pre-written or hard-coded. For example, Figure 9 displays the I/O Handler as a single module because what handles the input signals from the keyboard and mouse is the operating system of the computer being used (Windows, Linux, etc.); whereas the Screen Handler is a module with more detail due to the fact that what is being presented is the software being designed. Following this, several more modules can be seen in Figure 9, including the tracking module (the main extension of this project), the upload-code-to-robot module, and the video streaming component. All these modules are contained within the Screen Handler module, which essentially, builds the web page for users. The web page module is a higher class that contains the other three modules. All of these modules both send and receive data through the Network Adapter module, which is all mediated by the Web Based Processing module. These data are transformed to a visual representation of the robot s controls and current location and displayed using the I/O Handler, a hard-coded module found in Figure

11 Figure 9: Structure Chart of the Screen Handler The same pattern can be seen from Figure 8 to Figure 10. In Figure 8, the Architectural Diagram of the Clawbot Microcontroller Software can be seen from a static view. Figure 10 expands this diagram to reveal the dynamic modules of each module in Figure 8. For example, Figure 10 contains several modules that operate in the Central Processing Module. These include the Integrated Encoder Module, the Navigation Module, and the Motor Control Module. These three modules interact dynamically to control the robot. The Integrated Encoder Module reads feedback signals from the motors. These signals represent integers that increments based on how much the motor has turned. The navigation component then receives these integers from the IMEs. These integers are then transferred from the microcontroller software to the Network Adapter Module, which is simply the firmware/functionality of the VEXNet Wireless Adpater/Joystick combo; this is why this module is self-contained: all the code is pre-written and pre-packaged. Once the data is sent across the network, it will be transformed via the WCP. Concurrently, the CMS will take in data from the WCP through the Network Adapter Module. This data will be commands to the motors of the Clawbot, which is handled by the Motor Control module. The motors are actuated via signals on the microcontroller of the Clawbot. These signals are both read and written via I2C protocols, which is a daisy-chaining protocol embedded on the microcontroller. 11

12 Figure 10: Data Flow of the Processing Module of the Clawbot Microcontroller Software Graphical User Interface When the user goes to the WCP at vex.cs.fgcu.edu, they are presented with a log in prompt as shown in Figure 11. The site is created through the ASP.NET framework. 12

13 Figure 11: WCP Login Prompt When logged in, the user is presented with the control and tracking screen, as shown in Figure 12. There are forward, back, turn left, turn right, and stop controls for the drive motors, and arm up, arm down, claw open, and claw close controls for the claw arm of the ClawBot. Besides the direct controls for the ClawBot, there exists a programming utility that allows the user to upload new code or restore the default settings to the ClawBot. This is described later in detail under Section 3.1, which are the Developer s Instructions. 13

14 Figure 12: WCP Controls 1.4 Implementation and Testing The implementation of the Clawbotics Control Center requires the implementation of two pieces of software: the implementation of the Web-based Control Panel (WCP) and the implementation of the Clawbot Microcontroller Software (CMS). The previous report [1] had already implemented a basic software on the Clawbot microcontroller that allows the: Forward and backward movement of the robot Left and right turning of the robot Arm up and down of the robot s claw arm Claw close and open 14

15 1.4.1 Implementation of Clawbot Microcontroller Software The VEX ClawBot has most of its functionality embedded in the firmware of the microcontroller that cannot be touched. The software which controls the robots movements by sending and receiving data is created via the use of a provided API by the Purdue Robotics Operating System (PROS). This API is utilized using PROS IDE, which is an Eclipse extension that incorporates PROS libraries for the VEX. Since this project is concerned with implementing a tracking component, the previous software on the microcontroller will remain generally untouched. The main method used by the VEX microcontroller (also called the VEX Cortex) is void operatorcontrol(). This method defines all controls that are not hard-coded into the device or initialized on start up. The modules displayed in Figure 11 are defined here. The Navigation Module is comprised of two commands, getchar(), and a switch statement The former reads a single character off of the terminal sent from the WCP and returns it as an integer. That integer is then sent through the switch statement to trigger the motor control. // This sample code moves the robot forward at speed 75 while (1) { int command = getchar(); int leftencoder; int rightencoder; char * encoders; switch (command) { case 119: //if command is "w", go forward motorset(10, 75); motorset(1, 75); motorset(6, 0); motorset(7, 0); break;... case 102: imeget(0, &leftencoder); imeget(1, &rightencoder); snprintf(encoders, 33, %d,%d\n", leftencoder, rightencoder); puts(encoders);... case 103: imereset(0); imereset(1); 15

16 } } The Motor Control Module consist of multiple cases in the switch statement as triggered by the navigation module. When a specific character is sent, w for example, the system sets all four motors of the robot to their respective values. The method it uses is motorset(int, int). The first argument, channel, ranges from 1-10 and dictates which motor is triggered. The second argument, speed, determines the speed of the motor and ranges from -127 to 127, where a negative number indicates reversing. The hardware of the motors is physically connected to the integrated motor encoders, and whenever the motor rotates, the encoder reads these rotations. This data is stored on the encoders until the API is used to call upon the IME sensor module: imeget(int, int*) retrieves the current value of the encoder specified by the first argument and writes it to the memory location specified in the second argument. Once it has this value, it uses snprintf(char*, int, string, ) to format a string pointed at by the first argument, with size of the second, of format-string of the third, and values given to the format by all proceeding arguments: snprintf(encoders, 33, "%d,%d\n", leftencoder, rightencoder); The command used as an example writes a string to the pointer encoders of size 33. It is formatted to write as two doubles separated by a comma, in which the doubles are leftencoder, and rightencoder previously received by using imeget(). The WCP calls the VEX ClawBot to reset its values every time it writes, to ensure accurate readings. It does this by using the method imereset(int), which the ID of the encoder is the argument. All three of these modules work in conjunction with one another. The encoder is physically built in to the motor and the navigation instructs both the sensors and the motors. In order to control the physical system, the API accesses the I/O ports using the I2C protocol, which is a daisy-chaining protocol that allows multiple physical devices to be daisy-chained, allowing one input socket on the microcontroller. The PROS API also uses pre-built functions to read and write from the WCP via the Network Adapter Module (which is composed of the VEXNet Key 2.0 and joystick combo). 16

17 1.4.2 Implementation of Web-based Control Panel The WCP is a site constructed using the ASP.NET framework. It s primarily built using HTML, augmented with ASP.NET extensions and backed by a C# server-side code. The site compiles the code on start up and establishes its connection with the VEX ClawBot using a SerialPort as its Network Link. SerialPort sp = new SerialPort(Session["vexPort"].ToString(), , Parity.None) The SerialPort allows the server to communicate to the VEX joystick which then translates the instructions to the ClawBot. The Web-Based Processing is not called upon until the I/O handler receives a command from the user or a timer on the site s HTML: <asp:button id="button" onclick="vexstop" /> <asp:timer id="timer" interval="500" ontick="read" /> Behind the HTML, the I/O handler uses ASP.NET s event handlers to catch the command and have the server process the request. Each event handler needs the object that sent it and the arguments said object sent. protected void vexstop(object sender, EventArgs e) { writecommand("z"); } When the I/O handler has successfully received the instructions, the processing module takes over. The main method used is void writecommand(string command); The argument it receives is a single character that is determined based on command it received from the I/O handler, which it then uses to send the VEX ClawBot a command. To send the command, it opens the port, writes the command, closes the port. Given the function succeeds, it will hide the page element named lbloutofrange, or otherwise show it to alert the user the robot is out of range. private void writecommand(string command) { try { sp.open(); sp.write(command); sp.close(); 17

18 } lbloutofrange.visible = false; } } catch (Exception) { lbloutofrange.visible = true; } The details of each command are defined on the Clawbot itself, and the WCP gives up control once the command is sent. The commands currently accepted by the ClawBot are: Movement Commands (Forward, Backward, Left, Right, Stop) Claw Control (Claw Up, Claw Down, Claw Open, Claw Close) Integrated Motor Encoder Controls (Shutdown IMEs, Start IMEs, Get IME Values, Reset IME Values) Each of these commands are assigned a character to be sent using the writecommand(...) function. The second portion of the processing module is the read() function. The timer on the ASP.NET site calls this C# function which writes, reads, then writes again to the CMS before converting the data received to a usable form. private void read(){ string temp = ""; try { sp.open(); sp.write('f'); temp = sp.readline(); sp.write('g'); } catch (Exception) { lbloutofrange.visible = true; } finally { sp.close() } encoders[] = temp.split({','}); distance.push(new Tuple<encoder[0],encoder[1]>); } 18

19 The port is opened to sp.write( f ) to the ClawBot. f is defined to write the encoder values to the server, which sp.readline() then receives. sp.write( g ) is then used to tell the ClawBot to reset the values after they have been read. in the finally statement, the port is closed to avoid errors. When the data has been received, the encoder values are split into two strings, one on each side of the comma. A list distance<tuple<int,int>> stores the values of encoders in pairs to be used by the tracker module. The last portion of the processing module interacts directly with the tracker module. While the tracker draws the data, the calculate() method takes values from distance to instruct what to draw. The implementation of this is described in detail in section The site also contains two additional features that were developed in the previous project: the first is the Video Streaming Module that is initialized using the following line in ASP: <img id="streamimg" src=" /> The other is the ability to upload and restore the VEX ClawBot code to its default settings, or upload custom user-code. It accomplishes this by utilizing code created by the previous project to launch a.bat file located on the server. 19

20 1.4.3 Tracking Module The module that receives the most attention for the purposes of this project is the Tracking Module, which tracks the location of the robot. This is implemented via the TrackNMap class, coded in C# and implemented on the back-end server side. The basic operation of the Tracking Module occurs in the following steps: 1. A new TrackNMap object is initialized in the Page_Load event of the ASP webpage 2. This object creates a new Cartesian plane in its constructor, which is placed on the Default web page 3. Data are then read from the CMS (IME values) and fed into the TrackNMap object 4. The TrackNMap object transforms the data into coordinates which represent the location(s) of the Clawbot 5. The TrackNMap object then updates and re-renders the Cartesian plane to show these locations and will draw lines to represent the path traveled These five steps map onto requirement d, which states that The WCP shall display a Cartesian graph depicting the location of the VEX Clawbot and the path it has traveled in a web browser. In the following paragraphs, the details of each step will be expanded on using select code from the TrackNMap class. The first step, creating the TrackNMap object, is done using the following line: TrackNMap updatemap = new TrackNMap(); Once the object is initialized, a Bitmap object and a Graphics object are created to draw the basic Cartesian plane. This is done by drawing a rectangle and then each individual x-y line. This second step is implemented via the following code: objbitmap = new Bitmap(400, 400); objgraphics = Graphics.FromImage(objBitmap); // Draw border Pen pen = new Pen(Color.Black, 3.0F); objgraphics.drawrectangle(pen, 0, 0, 400, 400); // Draw x-y coordinate lines pen.color = Color.Gray; pen.width = 2.0F; objgraphics.drawline(pen, new Point(0, 200), new Point(400, 200)); objgraphics.drawline(pen, new Point(200, 0), new Point(200, 400)); // Draw rest of lines 20

21 pen.width = 1.0F; for (int i = 20; i < 401; i = i + 20){ objgraphics.drawline(pen, new Point(i, 0), new Point(i, 400)); objgraphics.drawline(pen, new Point(0, i), new Point(400, i)); } Once the Cartesian plane is reading, data can be read into the TrackNMap object. The data are read as ArrayList data structures, which contain lists of Tuple<int, int> objects. Much of the detail on how the data are read can be found above under the read() function. The fourth step encapsulates most of the mathematics of this project, as it details the calculation and transformation of raw IME values to coordinates. Since the IME values are integers describing how much a particular motor has moved, direction needs to be abstracted from this data and transformed properly to display turning. This requires some constants on the Clawbot s side so as to properly determine the ratio of IME ticks to arc length (or degree of rotation). Through rigorous testing, the following constants can be approximated: One foot of Clawbot movement = 700 Integrated Motor Encoder ticks One 360 degree rotation of Clawbot = 1900 Integrated Motor Encoder ticks The final step includes displaying the updated Cartesian plane on the website. This is implemented using ASP s Image Class, found under the System.Web.UI.WebControls namespace. The image is hosted on the web site using a ImageUrl parameter, which loads a file path. The reason it loads a file path is because the TrackNMap object generates the Cartesian graph and all its plotted coordinates (Clawbot locations) as a JPEG image. This is demonstrated in the following code: string mappath = "~\cartgraph.jpg"; objbitmap.save(mappath, System.Drawing.Imaging.ImageFormat.Jpeg); Once the graph is saved to the disk, the ASP code will load it from the disk onto the website. A sample of what the final graph will look like can be found in Figure 13. This figure displays the Cartesian graph along with plotted points and lines drawn from each point to represent the path the robot traveled. 21

22 Figure 13: Sample Cartesian Graph Tracking Testing With respect to the requirements documented in section 2, this section describes the test cases in order to display the functionality and reliability of the system. These test cases represent partial functionality of the numerous system required by the system to run properly. 22

23 Test ID 1 Title Related Requirements Directions Expected Result Actual Result Site Display a Navigate to vex.cs.fgcu.edu Log in using the username: fgcu password: vex The site should initially display a login prompt. If the user/password are entered successfully, the ClawBot Manager should be presented with its controls, video feed, and Cartesian graph. Upon entering the correct credentials (fgcu; vex), the Default page that contains the Clawbot controls, the video feed, and the Cartesian Graph loaded successfully. 23

24 Test ID 2 Title Related Requirements Directions Motor Control a, b, a, a, a Upon logging in, attempt to use the controls presented. Press each control button and allow the robot enough time to respond. Expected Result Actual Result Each button press should respond on the site based on browser styles of button clicks. If the clicks successfully are registered, the robot should respond accordingly based on the button pressed. Success: Robot responds to commands, despite some lag at seemingly random intervals. 24

25 Test ID 3 Title Related Requirements Directions Expected Result Actual Result VEX Robot Programming b, e Upon logging in, press Upload Default. If the uploading succeeds, the site will display a loading message and eventually display a success message, otherwise display an error. Success: Site displays Upload code then Successfully Uploaded! 25

26 Test ID 4 Title Related Requirements Directions Expected Result Actual Result Integrated Encoder Data b, c, d Upon logging in and moving the robot, view the Cartesian graph. When the robot is moved via its wheels, the Cartesian graph should display the movement of the robot. TBD 26

27 Test ID 5 Title Related Requirements Directions Expected Result Actual Result Camera feed b, c Upon logging in, view the presented camera feed. If the connection to the camera exists, the site should display a camera feed. Success: the site displays a live feed of the camera when camera is turned on. 27

28 2. Maintenance 2.1 Developer s Instructions In order to develop software for the VEX robot or make changes to the interface on the website which allows the user to control the robot, the developer must have the necessary software prerequisites which include Visual Studio 2013 (or Visual Studio Web Express 2013) and the PROS IDE. The hardware prerequisites are the VEX robot itself, the wireless joystick that connects to the VEX robot, and the ROCK server (provided and maintained by FGCU in the robotics lab). All previous code can be found at vex.cs.fgcu.edu. Log in with the credentials fgcu as the username and vex as the password. At the bottom of the website one can find a link in the footer that contains code for the website which is built in ASP.NET and C#, code for the VEX robot which is built in C, code for uploading custom VEX programs which is built in Java, and the PROS IDE installation package (this IDE is required to compile code for the VEX robot) Software Maintenance Most of the software development for the VEX robot takes place in Visual Studio Visual Studio 2013 was required of the previous developers, due to incompatibility issues with Visual Studio 2010 (this is to say that Visual Studio 2010 will not compile the ASP.NET website). For development of the VEX robot, the PROS IDE is required. Eclipse is also required to modify the upload-your-own-code mechanic that is featured on the website. An overview of each software, its tool, and its description is found below. 1. Main Website (vex.cs.fgcu.edu) - Visual Studio 2013 a. In order to make changes to the website (add new controls/functionality), the ClawBotManager project must be opened in Visual Studio From here, one can make changes by editing the respective files, each containing a portion of the website s functionality. b. There are three files that control the functionality of the website. They are Default, Login, and TrackNMap. Login controls the initial page which asks for the credentials. Default contains much of the website s main functionality, 28

29 including the controls that direct the VEX robot. TrackNMap is the custom class created to aid the tracking of the VEX robot. c. In order to implement any modifications to the website, one must Publish the project in Visual Studio 2013 to the correct folder on the ROCK server. These steps are described in detail in Section 2.1.2, Hardware Maintenance. 2. VEX Code - PROS IDE a. When adding new controls to the website (e.g. spin the VEX robot), these controls must reflect on the side of the VEX robot. This is to say that the VEX robot s microcontroller must be able to utilize these signals from the website once they are received via the Internet. This is done by code that is programmed on the microcontroller itself. To program the microcontroller, the PROS IDE is required to first compile the code written in C. From there, the main website can be used to upload this compiled code straight to the microcontroller, given the VEX robot is turned on and is connected to its joystick (more details about this connection in the further steps). b. Once compilation of the VEX robot s code is complete, a series of files are deposited into the workspace of the PROS IDE. Among them include opcontrol.c, the main of the VEX robot. To program the VEX robot with this code, log in to the main website and select this file using the Browse button. Then click upload and the file will be sent to the VEX robot and the robot will be reprogrammed. 3. Upload Code - Eclipse a. Much of the functionality of the upload-your-own-code mechanic is already complete and therefore little modification is needed. If modification is required for whatever reason, Eclipse should be used to modify the necessary Java files. The final modification should result in a JAR file which should then be embedded onto the main website so that when the user clicks Upload, the JAR will execute a series of BAT files that will send the compiled C code to the VEX robot and 29

30 reprogram the microcontroller. All these files, including the JAR and BAT files, can be found in the source code link described previously Hardware Maintenance When it comes to developing for the VEX robot, a couple of key hardware requirements are needed. These include the VEX joystick which is a necessary component in the remote networking of the VEX robot, and the ROCK server which hosts the main website. First, the joystick must be turned on and must be connected to the ROCK server via a special VEX Ethernet cable, as shown in Figure 14. The joystick must also be within range of the VEX robot so that a wireless connection can be maintained. Secondly, the ROCK server must be on. This is described in detail below in the following steps. Figure 14: Joystick Connectivity to ROCK Server 1. Connecting to the ROCK Server: In order to implement any modifications to the main website, the ROCK server must be accessed and the necessary Visual Studio files must be 30

31 deployed in C:\inetpub\wwwroot\VEX. To access the ROCK server, a remote desktop connection is required. a. IP Address: b. Password: Ask Instructor for password 2. Implementing Website Changes a. Navigate to C:\inetpub\wwwroot\VEX b. In Visual Studio 2013, select the Publish button and deploy to C:\inetpub\wwwroot\VEX 2.2 Operating Instructions To operate the VEX robot and manipulate/track it successfully requires little effort. All one needs is the VEX robot itself and a working client with a connection to the Internet. Since the robot s wireless capabilities is tied to the joystick controller, the robot must remain in range of the joystick in order to be manipulated/tracked (see Figure 14 above). 1. Plug in battery pack to the VEX microcontroller, as shown below. 31

32 Figure 15: Plugging Battery Pack into VEX Microcontroller 2. Turn on the VEX robot. An image of the switch is shown below. 32

33 Figure 16: Image of the VEX Power Switch 3. Turn on the Camera to enable live video feed (not required for operation). An image of the button is shown below. Figure 17: Image of the Camera s Power Button 4. Navigate to vex.cs.fgcu.edu on the computer connected to the Internet. This can be done on any client, even a mobile phone with an Internet connection. 5. Enter fgcu as the username and a respective password (ask Instructor for the password). 6. After the web page has downloaded, manipulate and track the robot using the controls, as shown in Figure 12 (repeated below). 33

34 Figure 12: Clawbot Control Panel 7. Once use of the Clawbot is finished, disconnect the robot by powering it off and plugging the battery pack back into the power adapter so that it may recharge. An image of the power adapter is shown below. Figure 18: Plugging Battery Pack into VEX Power Adapter 8. Optionally, it is possible to upload your own user code and program the VEX via the Internet (see section 2.1.1, Software Maintenance). 34

35 3. Troubleshooting Although the use of the VEX robot is relatively straight forward, some issues may occur. Listed below are common issues that may occur and the solution one should employ. Q: The VEX robot does not connect to the Internet/Server. A: Restart the VEX robot and the Joystick by turning both off and then back on. Q: Cannot connect to the website to control the VEX. A: Make sure the ROCK server is on and running. Q: The camera is not displaying any video feed. A: Check to make sure the camera on the VEX is turned on. There is a button located on the camera physically that controls the power. Otherwise, refresh the web page of the control panel. Q: The controls on the web page are not commanding the VEX robot. A: Power both the VEX robot and the joystick off and then turn them back on. If this does not solve the problem, navigate to the website and press the button Restore Default while the VEX is turned on. Wait for the page to refresh and try again. Q: The Program Clawbot functionality is reporting an error: Problem Uploading Code. A: Power both the VEX robot and the joystick off and then turn them back on. If this does not solve the problem, navigate to the website and press the button Restore Default while the VEX is turned on. Wait for the page to refresh and try again. Q: The VEX robot will not power on. A: Make sure the battery pack is fully charged and plugged into the VEX microcontroller. To charge the battery pack, find the power adapter, unplug the battery pack from the microcontroller, and plug the power adapter into the battery pack. Once charged, plug the battery pack back into the VEX microcontroller. 35

36 4. References [1] M. Grojean, N. Hart, <Remote Vehicle Networking>, Florida Gulf Coast University, 24 April 2014, URL: [2] Guide for Building the Clawbot, VEX Robotics, URL: [3] Motor 393 Integrated Encoder Module, VEX Robotics, URL: 36