Skip to content

My code from the in-lab portions of Mechatronics with Prof. Dan Block at UIUC (C)

Notifications You must be signed in to change notification settings

monk200/Mechatronics_with_OMAPL138DSP

Repository files navigation

Mechatronics_with_OMAPL138DSP

This repository contains code from the in-lab portions of Mechatronics with Prof. Dan Block at UIUC. The labs worked with the OMAP-L138 DSP+ARM processor on a robot car assembled and designed by Prof. Block. Course content available at http://coecsl.ece.illinois.edu/ge423/ although this link gets updated each semester (and I know the processor was changed the semester after I took the course). Each lab was completed in small steps with a lab partner.

Please do not steal the code if you are currently in the course, there is no guarentee that any of it is correct or up to date.

Content

I've done my best to separate each portion of each lab into small projects contained in their own folders. When I was talking the course, all of the code compiled and worked as intended but because I am editing the file structure and naming conventions it is very possible that the same code will not run correctly if it were plugged in to the same robot car today because of configuration file errors. The only file I wrote logic in will be named user_folderName.c in the source folder, where folderName is the name of the folder it is found under. Code Composer Studio's interface was also often used to edit the project's configuration file, which will be named folderName.cfg in the SYSBIOS folder.

A skeleton of the original files provided by the course can be created by running the executable Sp2019OMAPL138ProjCreator.exe under labfiles\Sp2019OMAPL138ProjCreatorFiles.

  • LEDctrlWithSwitches: The first task simply turned LEDs on while their corresponding switch was being pressed by creating the function checkswitches() in the main C file and a Clock object named CLK_checkswitches in the configuration file.
  • LEDsCountInBinary: Controls 5 LEDs on the robot to count in binary, incrementing every second and pausing the count if switch1 is pressed. Setting the correct LEDs was done in the function set5LEDS(cnt) and pausing the count was done in the fucntion countit(), both in the main C file. A Clock object named CLK_countit in the configuration file was also created to be able to increment the count once every second.
  • TCP_GUI.vi: A LABVIEW program that sets up a TCP/IP connection between LABVIEW and the robot's Linux program and provides a GUI for sending strings to be displayed on the robot's LCD screen. To set this up, right before running any code for the DSP processor type ./LVDSPComm into the terminal emulator and then launch TCP_GUI.vi. The DSP code can be run after the terminal acknowledges that a successful TCP/IP connection was made and the GUI can be used by typing a message into the "Send String" window and pressing the "Send" button.
  • SemaphoresAndTCP: Uses LVDSPComm to recieve and sent TCP/IP data between a LABVIEW GUI and the robot. A Clock object named lab2pt2clk, a Task named TASK_ComWithLinux, a Semaphore named semaphore0, and another Task named TASK_task0 were created in the configuration file. The functions ourclk(), ComWithLinus(), and task0() in the main C file work to send strings from the LABVIEW GUI to the LCD screen on the robot. The semaphore and task0 are used to count the number of times the "Send" button in the LABVIEW GUI is pressed.
  • introSWI: This lab created two software interrupts named SWI_counttime and SWI_loaded, as well as a Clock object named CLK_every1ms in the configuration file. The timeload(waittime) function is triggered by SWI_loaded and simulates a SWI with a heavy processing load while the every1ms() function posts SWI_counttime, which displays a counter on the robot's LCD screen (done in the counttime() function). Swapping which SWI has first and second priority demonstrates how interrupts need to be planned according to how much processing is done within them.
  • FrictionCompensation: This lab walked through using the motor's optical encoders to determine a conversion factor between motor angle and distance traveled, which was then used with the backwards difference rule to approximate the linear velocity of each motor. With this information, MATLAB was used to plot applied motor control effort vs estimated motor velocity with various different control efforts to determine the coulomb and viscous friction coefficients. These values are integrated into the main C file's control() function in such a way that when the control effort is 0 and the robot is pushed, the robot will roll for a long time as if it experiences no friction. The motor control processor used is the TI TMS320F28335. Demo video

Setup

All the code done in this class was edited and debugged using Code Composer Studio and the terminal emulator Tera Term. The robot car needs its serial port cable to be plugged into a JTAG USB attachment and the terminal emulator needs to be set to communicate with the COM port that the JTAG is plugged into and communicating at a 115200 baud rate. The COM port can be determined by searching through your computer's Device Manager. Turn the robot on and press any key while clicked into the terminal to boot Linux. After this, click the "Debug" button in Code Composer. Before pressing play to run the code, type "boot" into the terminal and hit enter, then wait until Linux is done booting. This will create a JTAG link and the process needs to be repeated whenever the robot is restarted or if the connect become flakey.

About

My code from the in-lab portions of Mechatronics with Prof. Dan Block at UIUC (C)

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published