Mech - User contributions [en]

Differential Drive Mobile Robot

2010-03-19T02:03:38Z

JakeWare: /* Electrical */

==Overview==

[[Image:Mobile_Robot_-_Parametric_-_Small.jpg|thumb|300px|center]]

===Summary===

The goal of this project was to create a low cost replacement for the popular E-Puck robot that was better suited to the needs of the current research projects here at Northwestern. The project also entailed developing a control library that would allow future users to easily interface with the robot and integrate it into their research. Specifically, the robot was to meet the following criteria:

===Mechanical Goals===

*Be of a similar size to the E-Puck

*Be significantly less expensive than the E-Puck

*Use stepper motors

*Be easy to manufacture

*Have an approximate run time of 1 hour

===Software Goals===

*Use the NU32 board for control logic

*Support wireless communication

*Develop a control library that can easily be included in a users code

*Allow the user to specify a velocity vector for the robot to follow

*Allow the user to specify the robot's configuration, (x,y,θ), in a global frame

*Allow the user to directly control the robot's wheel speeds

===Video Summary===

A video summary can be viewed [http://www.youtube.com/watch?v=5kB0zCvFP-g here]

 

==Mechanical==

[[Image:Mobile_Robot_-_Stepper_Motor.jpg|thumb|150px|Hybrid Stepper Motor|right]]

As previously stated, the robot needed to be easy to manufacture, inexpensive to make, and relatively small. These three goals guided each decision made in the mechanical design. The following sections will outline the design process for each mechanical component.

===Motors===

The motor choice was the most significant design decision in this project. Accordingly, much thought and research went into picking the hybrid stepper motors we ended up with. The stepper motor used in this project is a NEMA 17, bipolar (4 wire), [http://www.sparkfun.com/commerce/product_info.php?products_id=9238 hybrid stepper]. An image of this can be seen on the right.

*Standard Size:

:Very early in the motor search, it was decided that because this project was to be the foundation of future work, finding a motor that was readily available was a top priority. It quickly became clear that using a stepper motor that followed NEMA's motor standards would accomplish this. In doing so, any future project or research group that decides to use this project as a starting point will not need to locate the exact motor used here, but only a size 17 NEMA stepper motor.

*Hybrid Stepper:

:Although there are many types of stepper motors, we decided to use the hybrid stepper motor for this project. Aside from the fact that hybrid stepper motors are the most common type, they also have a higher resolution compared to a standard permanent magnet stepper motor. Both [http://en.wikipedia.org/wiki/Stepper_motor wikipedia] and [http://www.nmbtc.com/motors/hybrid-step/engineering/basic-introduction-of-step-motors.html NMB's website] have some good resources on stepper motor theory and operation.

*Bipolar:

:Although there are several possible winding configurations stepper motors can take, we chose a bipolar motor. This configuration demands the use of an H-bridge in the driving circuit, but allows for higher torque than a unipolar configuration.

*No Gearhead:

:The decision not to use a gearhead was a significant departure from the design of the E-puck. Although a gearhead allows for lower current draw, smaller motors (lighter robot) for any given torque, the gearheads themselves are often composed of fragile plastic components that break easily. Another drawback of geared stepper motors is their higher cost. The benefits and drawbacks of our decision are evident in the final design through its significantly higher weight and improved top speed.

*Cost:

:An average hybrid stepper motor from an established supplier like NMB, Lin Engineering, or Annaheim Automation costs around $40. Although the motors purchased from these companies may provide superior performance, the motors used in this project were purchased from SparkFun for $13 each and provide enough torque to propel our hefty robot at four times the speed of an E-Puck.

===Chassis===

[[Image:Mobile_Robot_-_CAD.jpg|thumb|150px|SolidWorks assembly of the robot|right]]

The focus of the chassis design was ease of manufacture. In order to achieve this, the chassis (and wheels) was designed so that it could be cut out of a single sheet of acrylic and simply glued together. The 6mm [http://www.mcmaster.com/#8560K354 acrylic] used came from McMaster-Carr. In order to minimize the amount of acrylic needed, it was assumed that the circuit board would act as the top of the robot and the front and back were left as short as possible without compromising strength. The final chassis dimensions are W:90mm, L:90mm, H:75mm. As can be seen below, the batteries rest on the motors themselves, and, therefore, do not require any additional mounting structure.

*Wheels:

:In order to allow for wheel size adjustments throughout the design and development process, the robot's wheels were made out of acrylic and cut on the laser cutter. The center hole was cut to have a 0.005" clearance so that the motor shaft would fit snugly and act to center the wheel. These [http://www.mcmaster.com/#57485K65 shaft collars] were super glued to the acrylic wheel and used to fix the wheel to the shaft.

:Note: If you are going to cut your own wheels on the laser cutter be mindful that the laser has a tendency to taper the edges of the wheels and does not cut a perfectly round circle due to the resolution of the carriage.

*Casters

:Because the robot has two wheels, it needed supports on both the front and back to prevent it from rocking back and forth or scraping the chassis on the floor. These [http://www.sparkfun.com/commerce/product_info.php?products_id=8909 casters] were used in order to reduce friction and allow for simple shim height adjustment.

:Note: Although the stainless steel ball in these casters will last longer, they make quite a bit of noise rattling around in their cage. The solution to this would be either to have them perfectly shimmed so they no longer are able to move, or order the equivalent caster with a plastic bearing.

===CAD Download===

The SolidWorks CAD files can be found [[Media:Mobile_Robot_-_CAD_Files.zip‎ | here]].

 

==Electrical==

[[Image:Mobile_Robot_-_Circuit.png|thumb|150px|Circuit Schematic|right]]
[[Image:Mobile_Robot_-_Breadboard_-_Small.jpg|thumb|150px|Initial breadboard version of the circuit|right]]
[[Image:Mobile_Robot_-_Proto_-_Small.jpg|thumb|150px|Final proto-board version of the circuit|right]]

===Circuit===

The circuit for the robot consists of the [[Introduction_to_the_PIC32|NU32 board]], two [http://www.st.com/stonline/books/pdf/docs/1330.pdf L293D h-bridges] (Digi-Key part number 497-2936-5-ND), an [http://www.sparkfun.com/commerce/product_info.php?products_id=8665 XBee wireless chip], connectors for the motors, and a power jack. A circuit diagram of the final version can be found to the right, as well as pictures of the initial breadboard version and final proto-board version.

===Batteries===

This project used Lithium Iron Phosphate (LiFePO4) batteries. These are essentially the next generation of Li-Ion batteries. Like Li-Ion cells, they have a high discharging current, but they are also non-explosive when charged improperly. A drawback is that their energy density is slightly less than a good Li-Ion cell. More information about this type of battery can be found [http://www.batteryspace.com/prod-specs/HLCF18650PLi-ion.ppt here]

For this project we used a battery pack that consisted of 4 3.2V A123Systems cells with its own integrated management circuit that prevents the user from charging/discharging the cells past a safe level and regulates the output current above a certain point.

Specifically, we used a 12.8V, 1500mAh, 4A max battery pack that can be purchased [http://www.batteryspace.com/lifepo418650battery128v1350mahflat1728wh4aratewithpcb.aspx here]. The charger for this battery pack can also be found [http://www.batteryspace.com/smartcharger15afor128vlifepo4batterypack4cells152vcut-offwith55mmx21mmmalebarrelplug.aspx here]

===Wireless===

One of the main goals of the robot was to have the ability to communicate wirelessly. The XBee wireless chip was used to fill this requirement. The XBee is a device that allows simple serial communication over a 2.4 GHz connection. By connecting the chip to ground, power, a transmit pin, and a receive pin, one is able to perform standard serial communication between two properly configured XBee chips. More information about the XBee can be found [http://www.sparkfun.com/commerce/product_info.php?products_id=8665 here].

 

==Software==

The control software for this project was written for the PIC32 with Microchip's MPLab IDE and C32 compiler. As stated in the original project goals, the code's final form needed to be in the form of a library that a future user can include and easily interface with. As such, the download file below contains three files. One is the main file that does little more than include the project code's header file and call one function in an infinite loop. The second file is a header file that contains the necessary function definitions. The third is the source code that contains all the code written for this project. This includes the interrupt routines, communication, motor control, odometry, and other smaller support functions.

Another goal of the software was to give the user access to three modes of control. These include wheel speed, position in (x,y,theta), and velocity vector control. Wheel speed control allows the user to directly specify each of the wheel speeds at a rate determined by their communication speed. This is the mode of control that the Wiimote code uses. (Also, for reference, it takes the current version of code 133ms of every second to decode these strings if they are being sent at 120Hz.) Position control allows the user to specify the robots position in a global frame relative to its starting position. Velocity vector control allows the user to give the robot a velocity vector stemming from the center of the front face that it must follow.

All of these modes of control support wireless communication through the XBee wireless chip. Furthermore, with 120Hz communication, and all else considered to be worst case scenario, this version of the code will only take about 30% of the available computation time.

===Code Download===

The fully documented code used in this project can be downloaded [[Media:Mobile_Robot_-_Code.zip | here]].

 

==Graphical User Interface==

[[Image:Mobile_Robot_-_Processing_GUI.jpg|thumb|150px|Processing window|right]]

A GUI was created in processing in order to demonstrate the functionality of the control software and facilitate testing.

An image of the GUI as it appears when it is first opened can be seen on the right.

===Modes of Operation===

The program has two modes of operation that can be selected with the "mode" button.

Note: The current mode can be discerned by looking at the white/black box next to the mode button and comparing with the legend at the bottom of the GUI

First, there is a position control mode that allows the user to send the robot to a point in a global frame. This is done by clicking in the white box that takes up the majority of the screen space. Once designated, the new position will appear with a number above it which marks its order relative to all the other requested positions. The white area maps to the surface that the robot is sitting on, and the x-axis, which the robot is aligned with, goes to the right of the screen from the origin at the center. The y-axis originates from the same location and goes upward. Both the location of the origin on the screen and the physical dimensions of the space that the screen area maps to are easily adjustable in the code.

Second, there is a velocity control mode that allows you to specify a velocity vector that the center of the front face of the robot must follow. As before, this vector is created by clicking in the white box at the center of the GUI. The robot is, once again aligned along the x-axis, and the magnitude of the velocity vector is specified by the distance from the origin to the point clicked.

Some other features include the ability to:

-stop the robot with the "stop" button

-move the origin to the robot's current position with the "reset" button

-send the robot back to its starting position with the "home" button

-specify the robot's wheel speed with the "speed" textbox

===Processing Download===

You can download the processing project [[Media:Mobile_Robot_Processing.zip | here]].

 

==Wii Demonstration==
This demo involved allowing a user to drive the robot using a Nintendo Wii remote (Wiimote). The user holds the Wiimote sideways in both hands such that the four arrows of the d-pad are in the left hand. This grip is similar to one used for many Wii games (and a lot like the original Nintendo Entertainment System controller). Holding different combinations of the "1" and "2" buttons then change how fast the robot moves when arrows are also being held. At any point in time, the user can hold the home button to send the robot back to its initial configuration. More details on this operation can be found in the WiiMain.c code included below.

The software relies on the [http://wiiuse.net/ wiiuse] library. The file linked below includes the important files from the wiiuse package (a header file, a lib file, and a dll file). The Wiimote is connected to a PC (must be running Windows) via bluetooth, and the wiiuse library is used to interpret the data sent to the PC. Once the data has been interpreted, it is sent to the robot over XBee.

In the file below, there is also an exe file of the WiiMain.c code. In order to execute this file, the wiiuse.dll must be in either the same directory as the executable, or in another directory that is included in Window's search path. To see Window's search path, simply type "echo %PATH%" into a command prompt. Additionally, this executable is assuming that the XBee chip is connected to the computer via "COM3". If a different port must be used, the exe file will need to be re-compiled after editing the pertinent lines in WiiMain.c.

===Wii Download===

A zip file with the necessary components to run this demo can be found [[Media:JS_JW_Wii_Demo.zip | here]].

 

==Future Work==

*Wheels:

:Although the final version of the robot performed well, there are several things that could be improved. One of the major factors for any imprecision in our odometry is the relatively low quality wheels that were used. During the prototyping phase of the project, it was very beneficial to have acrylic wheels so that new ones could be cut at any time. Unfortunately, the laser cutter does not do the best job of cutting a perfect circle and also tends to taper the edges of the wheels. Also, while it was convenient to make the wheels out of the same thickness acrylic as the body, thinner wheels would allow the robot to be more precise. Finally, rubber bands were used to increase traction between the wheel and the driving surface, but, after experimenting with the E-Puck, it is clear that far more traction could be generated with a carefully chosen rubber o-ring. All of this being said, it is our recommendation that before any further work is put into making this robot more precise, the wheels be replaced with something to [http://www.e-puck.org/images/epuck-look.jpg those] found on an E-Puck

*Chassis and PCB:

:Another significant improvement that could be made would be to reduce the size of the robot. This could be done by designing a pcb specifically for this application, and doing a redesign of the chassis. If both of these measures were done in tandem, the robot could be made significantly smaller and lighter.

*Motors:

:As far as weight goes, however, the main problem is the motor choice. As a proof of concept, the $12 stepper motors were a perfect choice. They had plenty of torque and were very physically robust. As the robot is refined, however, a top priority will likely be to make it lighter. If the motor price is increased to something closer to $40, there are a range of hybrid NEMA stepper motors that are still capable of producing the necessary torque, but are smaller and lighter. Some excellent resources to check are [http://www.anaheimautomation.com/ Anaheim Automation], [http://www.nmbtc.com/ NMB], and [http://www.linengineering.com/LinE/ Lin Engineering].

*Code:

:There are a few ways the code could be improved. At the moment, it uses two timers to perform its motor control functions. There are ways to do this with only one timer, and implementing these would free up one timer for the user. An example of this can be found in the E-Puck's motor control code. Another improvement would be the addition of some basic functions like forward(speed), reverse(speed), rotate_left(speed), etc... Although the functionality would be identical, changing the current convention of using two SetSpeed() commands to a single function call would both shorten the code and make it more readable. This could also be extended to other tasks performed in the current code that are done frequently.

 

==Team==
This project was created by John (Jake) Ware and Jarvis Schultz. Both are mechanical engineering PhD students at Northwestern University.

Contact:

"Jarvis Schultz" <jarvisschultz2012@u.northwestern.edu>

"John Ware" <johnware2015@u.northwestern.edu>

Differential Drive Mobile Robot

2010-03-19T02:03:27Z

JakeWare: /* Electrical */

==Overview==

[[Image:Mobile_Robot_-_Parametric_-_Small.jpg|thumb|300px|center]]

===Summary===

The goal of this project was to create a low cost replacement for the popular E-Puck robot that was better suited to the needs of the current research projects here at Northwestern. The project also entailed developing a control library that would allow future users to easily interface with the robot and integrate it into their research. Specifically, the robot was to meet the following criteria:

===Mechanical Goals===

*Be of a similar size to the E-Puck

*Be significantly less expensive than the E-Puck

*Use stepper motors

*Be easy to manufacture

*Have an approximate run time of 1 hour

===Software Goals===

*Use the NU32 board for control logic

*Support wireless communication

*Develop a control library that can easily be included in a users code

*Allow the user to specify a velocity vector for the robot to follow

*Allow the user to specify the robot's configuration, (x,y,θ), in a global frame

*Allow the user to directly control the robot's wheel speeds

===Video Summary===

A video summary can be viewed [http://www.youtube.com/watch?v=5kB0zCvFP-g here]

 

==Mechanical==

[[Image:Mobile_Robot_-_Stepper_Motor.jpg|thumb|150px|Hybrid Stepper Motor|right]]

As previously stated, the robot needed to be easy to manufacture, inexpensive to make, and relatively small. These three goals guided each decision made in the mechanical design. The following sections will outline the design process for each mechanical component.

===Motors===

The motor choice was the most significant design decision in this project. Accordingly, much thought and research went into picking the hybrid stepper motors we ended up with. The stepper motor used in this project is a NEMA 17, bipolar (4 wire), [http://www.sparkfun.com/commerce/product_info.php?products_id=9238 hybrid stepper]. An image of this can be seen on the right.

*Standard Size:

:Very early in the motor search, it was decided that because this project was to be the foundation of future work, finding a motor that was readily available was a top priority. It quickly became clear that using a stepper motor that followed NEMA's motor standards would accomplish this. In doing so, any future project or research group that decides to use this project as a starting point will not need to locate the exact motor used here, but only a size 17 NEMA stepper motor.

*Hybrid Stepper:

:Although there are many types of stepper motors, we decided to use the hybrid stepper motor for this project. Aside from the fact that hybrid stepper motors are the most common type, they also have a higher resolution compared to a standard permanent magnet stepper motor. Both [http://en.wikipedia.org/wiki/Stepper_motor wikipedia] and [http://www.nmbtc.com/motors/hybrid-step/engineering/basic-introduction-of-step-motors.html NMB's website] have some good resources on stepper motor theory and operation.

*Bipolar:

:Although there are several possible winding configurations stepper motors can take, we chose a bipolar motor. This configuration demands the use of an H-bridge in the driving circuit, but allows for higher torque than a unipolar configuration.

*No Gearhead:

:The decision not to use a gearhead was a significant departure from the design of the E-puck. Although a gearhead allows for lower current draw, smaller motors (lighter robot) for any given torque, the gearheads themselves are often composed of fragile plastic components that break easily. Another drawback of geared stepper motors is their higher cost. The benefits and drawbacks of our decision are evident in the final design through its significantly higher weight and improved top speed.

*Cost:

:An average hybrid stepper motor from an established supplier like NMB, Lin Engineering, or Annaheim Automation costs around $40. Although the motors purchased from these companies may provide superior performance, the motors used in this project were purchased from SparkFun for $13 each and provide enough torque to propel our hefty robot at four times the speed of an E-Puck.

===Chassis===

[[Image:Mobile_Robot_-_CAD.jpg|thumb|150px|SolidWorks assembly of the robot|right]]

The focus of the chassis design was ease of manufacture. In order to achieve this, the chassis (and wheels) was designed so that it could be cut out of a single sheet of acrylic and simply glued together. The 6mm [http://www.mcmaster.com/#8560K354 acrylic] used came from McMaster-Carr. In order to minimize the amount of acrylic needed, it was assumed that the circuit board would act as the top of the robot and the front and back were left as short as possible without compromising strength. The final chassis dimensions are W:90mm, L:90mm, H:75mm. As can be seen below, the batteries rest on the motors themselves, and, therefore, do not require any additional mounting structure.

*Wheels:

:In order to allow for wheel size adjustments throughout the design and development process, the robot's wheels were made out of acrylic and cut on the laser cutter. The center hole was cut to have a 0.005" clearance so that the motor shaft would fit snugly and act to center the wheel. These [http://www.mcmaster.com/#57485K65 shaft collars] were super glued to the acrylic wheel and used to fix the wheel to the shaft.

:Note: If you are going to cut your own wheels on the laser cutter be mindful that the laser has a tendency to taper the edges of the wheels and does not cut a perfectly round circle due to the resolution of the carriage.

*Casters

:Because the robot has two wheels, it needed supports on both the front and back to prevent it from rocking back and forth or scraping the chassis on the floor. These [http://www.sparkfun.com/commerce/product_info.php?products_id=8909 casters] were used in order to reduce friction and allow for simple shim height adjustment.

:Note: Although the stainless steel ball in these casters will last longer, they make quite a bit of noise rattling around in their cage. The solution to this would be either to have them perfectly shimmed so they no longer are able to move, or order the equivalent caster with a plastic bearing.

===CAD Download===

The SolidWorks CAD files can be found [[Media:Mobile_Robot_-_CAD_Files.zip‎ | here]].

 

==Electrical==

[[Image:Mobile_Robot_-_Circuit.png|thumb|150px|Circuit Schematic|right]]
[[Image:Mobile_Robot_-_Breadboard_-_Small.jpg|thumb|150px|Initial breadboard version of the circuit|right]]
[[Image:Mobile_Robot_-_Proto_-_Small.jpg|thumb|150px|Final proto-board version of the circuit|right]]

===Circuit===

The circuit for the robot consists of the [[Introduction_to_the_PIC32|NU32 board]], two [http://www.st.com/stonline/books/pdf/docs/1330.pdf L293D h-bridges] (Digi-Key part number 497-2936-5-ND), an [http://www.sparkfun.com/commerce/product_info.php?products_id=8665 XBee wireless chip], connectors for the motors, and a power jack. A circuit diagram of the final version can be found to the right, as well as pictures of the initial breadboard version and final proto-board version.

===Batteries===

This project used Lithium Iron Phosphate (LiFePO4) batteries. These are essentially the next generation of Li-Ion batteries. Like Li-Ion cells, they have a high discharging current, but they are also non-explosive when charged improperly. A drawback is that their energy density is slightly less than a good Li-Ion cell. More information about this type of battery can be found [http://www.batteryspace.com/prod-specs/HLCF18650PLi-ion.ppt here]

For this project we used a battery pack that consisted of 4 3.2V A123Systems cells with its own integrated management circuit that prevents the user from charging/discharging the cells past a safe level and regulates the output current above a certain point.

Specifically, we used a 12.8V, 1500mAh, 4A max battery pack that can be purchased [http://www.batteryspace.com/lifepo418650battery128v1350mahflat1728wh4aratewithpcb.aspx here]. The charger for this battery pack can also be found [http://www.batteryspace.com/smartcharger15afor128vlifepo4batterypack4cells152vcut-offwith55mmx21mmmalebarrelplug.aspx here]

===Wireless===

One of the main goals of the robot was to have the ability to communicate wirelessly. The XBee wireless chip was used to fill this requirement. The XBee is a device that allows simple serial communication over a 2.4 GHz connection. By connecting the chip to ground, power, a transmit pin, and a receive pin, one is able to perform standard serial communication between two properly configured XBee chips. More information about the XBee can be found [http://www.sparkfun.com/commerce/product_info.php?products_id=8665 here].
 

==Software==

The control software for this project was written for the PIC32 with Microchip's MPLab IDE and C32 compiler. As stated in the original project goals, the code's final form needed to be in the form of a library that a future user can include and easily interface with. As such, the download file below contains three files. One is the main file that does little more than include the project code's header file and call one function in an infinite loop. The second file is a header file that contains the necessary function definitions. The third is the source code that contains all the code written for this project. This includes the interrupt routines, communication, motor control, odometry, and other smaller support functions.

Another goal of the software was to give the user access to three modes of control. These include wheel speed, position in (x,y,theta), and velocity vector control. Wheel speed control allows the user to directly specify each of the wheel speeds at a rate determined by their communication speed. This is the mode of control that the Wiimote code uses. (Also, for reference, it takes the current version of code 133ms of every second to decode these strings if they are being sent at 120Hz.) Position control allows the user to specify the robots position in a global frame relative to its starting position. Velocity vector control allows the user to give the robot a velocity vector stemming from the center of the front face that it must follow.

All of these modes of control support wireless communication through the XBee wireless chip. Furthermore, with 120Hz communication, and all else considered to be worst case scenario, this version of the code will only take about 30% of the available computation time.

===Code Download===

The fully documented code used in this project can be downloaded [[Media:Mobile_Robot_-_Code.zip | here]].

 

==Graphical User Interface==

[[Image:Mobile_Robot_-_Processing_GUI.jpg|thumb|150px|Processing window|right]]

A GUI was created in processing in order to demonstrate the functionality of the control software and facilitate testing.

An image of the GUI as it appears when it is first opened can be seen on the right.

===Modes of Operation===

The program has two modes of operation that can be selected with the "mode" button.

Note: The current mode can be discerned by looking at the white/black box next to the mode button and comparing with the legend at the bottom of the GUI

First, there is a position control mode that allows the user to send the robot to a point in a global frame. This is done by clicking in the white box that takes up the majority of the screen space. Once designated, the new position will appear with a number above it which marks its order relative to all the other requested positions. The white area maps to the surface that the robot is sitting on, and the x-axis, which the robot is aligned with, goes to the right of the screen from the origin at the center. The y-axis originates from the same location and goes upward. Both the location of the origin on the screen and the physical dimensions of the space that the screen area maps to are easily adjustable in the code.

Second, there is a velocity control mode that allows you to specify a velocity vector that the center of the front face of the robot must follow. As before, this vector is created by clicking in the white box at the center of the GUI. The robot is, once again aligned along the x-axis, and the magnitude of the velocity vector is specified by the distance from the origin to the point clicked.

Some other features include the ability to:

-stop the robot with the "stop" button

-move the origin to the robot's current position with the "reset" button

-send the robot back to its starting position with the "home" button

-specify the robot's wheel speed with the "speed" textbox

===Processing Download===

You can download the processing project [[Media:Mobile_Robot_Processing.zip | here]].

 

==Wii Demonstration==
This demo involved allowing a user to drive the robot using a Nintendo Wii remote (Wiimote). The user holds the Wiimote sideways in both hands such that the four arrows of the d-pad are in the left hand. This grip is similar to one used for many Wii games (and a lot like the original Nintendo Entertainment System controller). Holding different combinations of the "1" and "2" buttons then change how fast the robot moves when arrows are also being held. At any point in time, the user can hold the home button to send the robot back to its initial configuration. More details on this operation can be found in the WiiMain.c code included below.

The software relies on the [http://wiiuse.net/ wiiuse] library. The file linked below includes the important files from the wiiuse package (a header file, a lib file, and a dll file). The Wiimote is connected to a PC (must be running Windows) via bluetooth, and the wiiuse library is used to interpret the data sent to the PC. Once the data has been interpreted, it is sent to the robot over XBee.

In the file below, there is also an exe file of the WiiMain.c code. In order to execute this file, the wiiuse.dll must be in either the same directory as the executable, or in another directory that is included in Window's search path. To see Window's search path, simply type "echo %PATH%" into a command prompt. Additionally, this executable is assuming that the XBee chip is connected to the computer via "COM3". If a different port must be used, the exe file will need to be re-compiled after editing the pertinent lines in WiiMain.c.

===Wii Download===

A zip file with the necessary components to run this demo can be found [[Media:JS_JW_Wii_Demo.zip | here]].

 

==Future Work==

*Wheels:

:Although the final version of the robot performed well, there are several things that could be improved. One of the major factors for any imprecision in our odometry is the relatively low quality wheels that were used. During the prototyping phase of the project, it was very beneficial to have acrylic wheels so that new ones could be cut at any time. Unfortunately, the laser cutter does not do the best job of cutting a perfect circle and also tends to taper the edges of the wheels. Also, while it was convenient to make the wheels out of the same thickness acrylic as the body, thinner wheels would allow the robot to be more precise. Finally, rubber bands were used to increase traction between the wheel and the driving surface, but, after experimenting with the E-Puck, it is clear that far more traction could be generated with a carefully chosen rubber o-ring. All of this being said, it is our recommendation that before any further work is put into making this robot more precise, the wheels be replaced with something to [http://www.e-puck.org/images/epuck-look.jpg those] found on an E-Puck

*Chassis and PCB:

:Another significant improvement that could be made would be to reduce the size of the robot. This could be done by designing a pcb specifically for this application, and doing a redesign of the chassis. If both of these measures were done in tandem, the robot could be made significantly smaller and lighter.

*Motors:

:As far as weight goes, however, the main problem is the motor choice. As a proof of concept, the $12 stepper motors were a perfect choice. They had plenty of torque and were very physically robust. As the robot is refined, however, a top priority will likely be to make it lighter. If the motor price is increased to something closer to $40, there are a range of hybrid NEMA stepper motors that are still capable of producing the necessary torque, but are smaller and lighter. Some excellent resources to check are [http://www.anaheimautomation.com/ Anaheim Automation], [http://www.nmbtc.com/ NMB], and [http://www.linengineering.com/LinE/ Lin Engineering].

*Code:

:There are a few ways the code could be improved. At the moment, it uses two timers to perform its motor control functions. There are ways to do this with only one timer, and implementing these would free up one timer for the user. An example of this can be found in the E-Puck's motor control code. Another improvement would be the addition of some basic functions like forward(speed), reverse(speed), rotate_left(speed), etc... Although the functionality would be identical, changing the current convention of using two SetSpeed() commands to a single function call would both shorten the code and make it more readable. This could also be extended to other tasks performed in the current code that are done frequently.

 

==Team==
This project was created by John (Jake) Ware and Jarvis Schultz. Both are mechanical engineering PhD students at Northwestern University.

Contact:

"Jarvis Schultz" <jarvisschultz2012@u.northwestern.edu>

"John Ware" <johnware2015@u.northwestern.edu>

Differential Drive Mobile Robot

2010-03-19T02:03:08Z

JakeWare: /* Overview */

Differential Drive Mobile Robot

2010-03-19T02:02:40Z

JakeWare: /* Software */

Differential Drive Mobile Robot

2010-03-19T01:47:53Z

JakeWare:

==Overview==

[[Image:Mobile_Robot_-_Parametric_-_Small.jpg|thumb|300px|center]]

===Summary===

The goal of this project was to create a low cost replacement for the popular E-Puck robot that was better suited to the needs of the current research projects here at Northwestern. The project also entailed developing a control library that would allow future users to easily interface with the robot and integrate it into their research. Specifically, the robot was to meet the following criteria:

===Mechanical Goals===

*Be of a similar size to the E-Puck

*Be significantly less expensive than the E-Puck

*Use stepper motors

*Be easy to manufacture

*Have an approximate run time of 1 hour

===Software Goals===

*Use the NU32 board for control logic

*Support wireless communication

*Develop a control library that can easily be included in a users code

*Allow the user to specify a velocity vector for the robot to follow

*Allow the user to specify the robot's configuration, (x,y,θ), in a global frame

*Allow the user to directly control the robot's wheel speeds

===Video Summary===

A video summary can be viewed [http://www.youtube.com/watch?v=5kB0zCvFP-g here]

 

==Mechanical==

[[Image:Mobile_Robot_-_Stepper_Motor.jpg|thumb|150px|Hybrid Stepper Motor|right]]

As previously stated, the robot needed to be easy to manufacture, inexpensive to make, and relatively small. These three goals guided each decision made in the mechanical design. The following sections will outline the design process for each mechanical component.

===Motors===

The motor choice was the most significant design decision in this project. Accordingly, much thought and research went into picking the hybrid stepper motors we ended up with. The stepper motor used in this project is a NEMA 17, bipolar (4 wire), [http://www.sparkfun.com/commerce/product_info.php?products_id=9238 hybrid stepper]. An image of this can be seen on the right.

*Standard Size:

:Very early in the motor search, it was decided that because this project was to be the foundation of future work, finding a motor that was readily available was a top priority. It quickly became clear that using a stepper motor that followed NEMA's motor standards would accomplish this. In doing so, any future project or research group that decides to use this project as a starting point will not need to locate the exact motor used here, but only a size 17 NEMA stepper motor.

*Hybrid Stepper:

:Although there are many types of stepper motors, we decided to use the hybrid stepper motor for this project. Aside from the fact that hybrid stepper motors are the most common type, they also have a higher resolution compared to a standard permanent magnet stepper motor. Both [http://en.wikipedia.org/wiki/Stepper_motor wikipedia] and [http://www.nmbtc.com/motors/hybrid-step/engineering/basic-introduction-of-step-motors.html NMB's website] have some good resources on stepper motor theory and operation.

*Bipolar:

:Although there are several possible winding configurations stepper motors can take, we chose a bipolar motor. This configuration demands the use of an H-bridge in the driving circuit, but allows for higher torque than a unipolar configuration.

*No Gearhead:

:The decision not to use a gearhead was a significant departure from the design of the E-puck. Although a gearhead allows for lower current draw, smaller motors (lighter robot) for any given torque, the gearheads themselves are often composed of fragile plastic components that break easily. Another drawback of geared stepper motors is their higher cost. The benefits and drawbacks of our decision are evident in the final design through its significantly higher weight and improved top speed.

*Cost:

:An average hybrid stepper motor from an established supplier like NMB, Lin Engineering, or Annaheim Automation costs around $40. Although the motors purchased from these companies may provide superior performance, the motors used in this project were purchased from SparkFun for $13 each and provide enough torque to propel our hefty robot at four times the speed of an E-Puck.

===Chassis===

[[Image:Mobile_Robot_-_CAD.jpg|thumb|150px|SolidWorks assembly of the robot|right]]

The focus of the chassis design was ease of manufacture. In order to achieve this, the chassis (and wheels) was designed so that it could be cut out of a single sheet of acrylic and simply glued together. The 6mm [http://www.mcmaster.com/#8560K354 acrylic] used came from McMaster-Carr. In order to minimize the amount of acrylic needed, it was assumed that the circuit board would act as the top of the robot and the front and back were left as short as possible without compromising strength. The final chassis dimensions are W:90mm, L:90mm, H:75mm. As can be seen below, the batteries rest on the motors themselves, and, therefore, do not require any additional mounting structure.

*Wheels:

:In order to allow for wheel size adjustments throughout the design and development process, the robot's wheels were made out of acrylic and cut on the laser cutter. The center hole was cut to have a 0.005" clearance so that the motor shaft would fit snugly and act to center the wheel. These [http://www.mcmaster.com/#57485K65 shaft collars] were super glued to the acrylic wheel and used to fix the wheel to the shaft.

:Note: If you are going to cut your own wheels on the laser cutter be mindful that the laser has a tendency to taper the edges of the wheels and does not cut a perfectly round circle due to the resolution of the carriage.

*Casters

:Because the robot has two wheels, it needed supports on both the front and back to prevent it from rocking back and forth or scraping the chassis on the floor. These [http://www.sparkfun.com/commerce/product_info.php?products_id=8909 casters] were used in order to reduce friction and allow for simple shim height adjustment.

:Note: Although the stainless steel ball in these casters will last longer, they make quite a bit of noise rattling around in their cage. The solution to this would be either to have them perfectly shimmed so they no longer are able to move, or order the equivalent caster with a plastic bearing.

===CAD Download===

The SolidWorks CAD files can be found [[Media:Mobile_Robot_-_CAD_Files.zip‎ | here]].

 

==Electrical==

[[Image:Mobile_Robot_-_Circuit.png|thumb|150px|Circuit Schematic|right]]
[[Image:Mobile_Robot_-_Breadboard_-_Small.jpg|thumb|150px|Initial breadboard version of the circuit|right]]
[[Image:Mobile_Robot_-_Proto_-_Small.jpg|thumb|150px|Final proto-board version of the circuit|right]]

===Circuit===

The circuit for the robot consists of the [[Introduction_to_the_PIC32|NU32 board]], two [http://www.st.com/stonline/books/pdf/docs/1330.pdf L293D h-bridges] (Digi-Key part number 497-2936-5-ND), an [http://www.sparkfun.com/commerce/product_info.php?products_id=8665 XBee wireless chip], connectors for the motors, and a power jack. A circuit diagram of the final version can be found to the right, as well as pictures of the initial breadboard version and final proto-board version.

===Batteries===

This project used Lithium Iron Phosphate (LiFePO4) batteries. These are essentially the next generation of Li-Ion batteries. Like Li-Ion cells, they have a high discharging current, but they are also non-explosive when charged improperly. A drawback is that their energy density is slightly less than a good Li-Ion cell. More information about this type of battery can be found [http://www.batteryspace.com/prod-specs/HLCF18650PLi-ion.ppt here]

For this project we used a battery pack that consisted of 4 3.2V A123Systems cells with its own integrated management circuit that prevents the user from charging/discharging the cells past a safe level and regulates the output current above a certain point.

Specifically, we used a 12.8V, 1500mAh, 4A max battery pack that can be purchased [http://www.batteryspace.com/lifepo418650battery128v1350mahflat1728wh4aratewithpcb.aspx here]. The charger for this battery pack can also be found [http://www.batteryspace.com/smartcharger15afor128vlifepo4batterypack4cells152vcut-offwith55mmx21mmmalebarrelplug.aspx here]

===Wireless===

One of the main goals of the robot was to have the ability to communicate wirelessly. The XBee wireless chip was used to fill this requirement. The XBee is a device that allows simple serial communication over a 2.4 GHz connection. By connecting the chip to ground, power, a transmit pin, and a receive pin, one is able to perform standard serial communication between two properly configured XBee chips. More information about the XBee can be found [http://www.sparkfun.com/commerce/product_info.php?products_id=8665 here].

 

==Software==

The control software for this project was written for the PIC32 with Microchip's MPLab IDE and C32 compiler. As stated in the original project goals

 

==Graphical User Interface==

[[Image:Mobile_Robot_-_Processing_GUI.jpg|thumb|150px|Processing window|right]]

A GUI was created in processing in order to demonstrate the functionality of the control software and facilitate testing.

An image of the GUI as it appears when it is first opened can be seen on the right.

===Modes of Operation===

The program has two modes of operation that can be selected with the "mode" button.

Note: The current mode can be discerned by looking at the white/black box next to the mode button and comparing with the legend at the bottom of the GUI

First, there is a position control mode that allows the user to send the robot to a point in a global frame. This is done by clicking in the white box that takes up the majority of the screen space. Once designated, the new position will appear with a number above it which marks its order relative to all the other requested positions. The white area maps to the surface that the robot is sitting on, and the x-axis, which the robot is aligned with, goes to the right of the screen from the origin at the center. The y-axis originates from the same location and goes upward. Both the location of the origin on the screen and the physical dimensions of the space that the screen area maps to are easily adjustable in the code.

Second, there is a velocity control mode that allows you to specify a velocity vector that the center of the front face of the robot must follow. As before, this vector is created by clicking in the white box at the center of the GUI. The robot is, once again aligned along the x-axis, and the magnitude of the velocity vector is specified by the distance from the origin to the point clicked.

Some other features include the ability to:

-stop the robot with the "stop" button

-move the origin to the robot's current position with the "reset" button

-send the robot back to its starting position with the "home" button

-specify the robot's wheel speed with the "speed" textbox

===Processing Download===

You can download the processing project [[Media:Mobile_Robot_Processing.zip | here]].

 

==Wii Demonstration==
This demo involved allowing a user to drive the robot using a Nintendo Wii remote (Wiimote). The user holds the Wiimote sideways in both hands such that the four arrows of the d-pad are in the left hand. This grip is similar to one used for many Wii games (and a lot like the original Nintendo Entertainment System controller). Holding different combinations of the "1" and "2" buttons then change how fast the robot moves when arrows are also being held. At any point in time, the user can hold the home button to send the robot back to its initial configuration. More details on this operation can be found in the WiiMain.c code included below.

The software relies on the [http://wiiuse.net/ wiiuse] library. The file linked below includes the important files from the wiiuse package (a header file, a lib file, and a dll file). The Wiimote is connected to a PC (must be running Windows) via bluetooth, and the wiiuse library is used to interpret the data sent to the PC. Once the data has been interpreted, it is sent to the robot over XBee.

In the file below, there is also an exe file of the WiiMain.c code. In order to execute this file, the wiiuse.dll must be in either the same directory as the executable, or in another directory that is included in Window's search path. To see Window's search path, simply type "echo %PATH%" into a command prompt. Additionally, this executable is assuming that the XBee chip is connected to the computer via "COM3". If a different port must be used, the exe file will need to be re-compiled after editing the pertinent lines in WiiMain.c.

===Wii Download===

A zip file with the necessary components to run this demo can be found [[Media:JS_JW_Wii_Demo.zip | here]].

 

==Future Work==

*Wheels:

:Although the final version of the robot performed well, there are several things that could be improved. One of the major factors for any imprecision in our odometry is the relatively low quality wheels that were used. During the prototyping phase of the project, it was very beneficial to have acrylic wheels so that new ones could be cut at any time. Unfortunately, the laser cutter does not do the best job of cutting a perfect circle and also tends to taper the edges of the wheels. Also, while it was convenient to make the wheels out of the same thickness acrylic as the body, thinner wheels would allow the robot to be more precise. Finally, rubber bands were used to increase traction between the wheel and the driving surface, but, after experimenting with the E-Puck, it is clear that far more traction could be generated with a carefully chosen rubber o-ring. All of this being said, it is our recommendation that before any further work is put into making this robot more precise, the wheels be replaced with something to [http://www.e-puck.org/images/epuck-look.jpg those] found on an E-Puck

*Chassis and PCB:

:Another significant improvement that could be made would be to reduce the size of the robot. This could be done by designing a pcb specifically for this application, and doing a redesign of the chassis. If both of these measures were done in tandem, the robot could be made significantly smaller and lighter.

*Motors:

:As far as weight goes, however, the main problem is the motor choice. As a proof of concept, the $12 stepper motors were a perfect choice. They had plenty of torque and were very physically robust. As the robot is refined, however, a top priority will likely be to make it lighter. If the motor price is increased to something closer to $40, there are a range of hybrid NEMA stepper motors that are still capable of producing the necessary torque, but are smaller and lighter. Some excellent resources to check are [http://www.anaheimautomation.com/ Anaheim Automation], [http://www.nmbtc.com/ NMB], and [http://www.linengineering.com/LinE/ Lin Engineering].

*Code:

:There are a few ways the code could be improved. At the moment, it uses two timers to perform its motor control functions. There are ways to do this with only one timer, and implementing these would free up one timer for the user. An example of this can be found in the E-Puck's motor control code. Another improvement would be the addition of some basic functions like forward(speed), reverse(speed), rotate_left(speed), etc... Although the functionality would be identical, changing the current convention of using two SetSpeed() commands to a single function call would both shorten the code and make it more readable. This could also be extended to other tasks performed in the current code that are done frequently.

 

==Team==
This project was created by John (Jake) Ware and Jarvis Schultz. Both are mechanical engineering PhD students at Northwestern University.

Contact:

"Jarvis Schultz" <jarvisschultz2012@u.northwestern.edu>

"John Ware" <johnware2015@u.northwestern.edu>

2010-03-19T01:24:31Z

JakeWare:

See the '''[[ME 333 end of course schedule]]'''.

Final projects for ME 333 in years 2000-2007 can be found
'''[http://lims.mech.northwestern.edu/~design/mechatronics/ here]'''.

__TOC__

== ME 333 Final Projects 2010 ==

=== [[Sample Project Title]] ===

[[Image:Persistence of Vison Display|thumb|150px|Project photo caption.|right]]

You can copy and paste this wiki code to start your wiki page (but don't erase this code). Then replace this text with your own. A few sentences describing what your project does, with a link to a youtube video. Look at other final project wiki pages for ideas, but see [[ME 333 end of course schedule]] for more information on what should be included on your wiki page.

 

=== [[Furuta Pendulum]] ===

[[Image:Picture 1.png|thumb|150px|Furuta Pendulum|right]]

The Furuta pendulum, so named because it was first developed by Katsuhisa Furuta, is a rotational inverted pendulum. In other words, the horizontal arm, which rotates in the horizontal plane, drives the movement of the vertical arm, which is free to rotate in the vertical plane. Out objective was to build a Furuta pendulum that would hold the vertical arm up, as you can see from the [http://www.youtube.com/watch?v=7DtFLKgNUk4 demonstration video].

 

=== [[Music from the Heart -- Music Suit]] ===

[[Image:Music from the heart overview.jpg|thumb|150px|The "music suit" on James, with heart rate detector on his finger.|right]]

This project attempted to create a natural form of musical expression by connecting sensors to the body. Six tilt switches were attached to the wrist, ankles, and shoulders, each controlling a single pitch from the [http://en.wikipedia.org/wiki/Pentatonic_scale pentatonic scale]. The heart beat was obtained using [http://en.wikipedia.org/wiki/Photoplethysmograph photoplethysmography] on the user's finger, and this signal was used to strike a drum in sync with the heart beat.

For a video demonstration, click [http://www.youtube.com/watch?v=YyipByy7m6I here].

 

=== [[Conservation of Angular Momentum Locomotion Robot (Fluffbot)]] ===

[[Image:Isometric view of Fluffbot guts.jpg|thumb|150px|The Fluffbot without Fluff.|right]]

Cute fluffy robot that uses conservation of angular momentum to move forward and backward. The robot's momentum wheel accelerates in the floor-plane. The robot's net angular momentum must remain zero-- a steering wheel guides the Fluffbot to accelerate in the opposite direction. This moves the robot forward in a curved path. The momentum wheel and steering wheel then change direction of acceleration. This repeated process moves the Fluffbot forward in a sinusoidal path.

 

=== [[Differential Drive Mobile Robot]] ===

[[Image:Mobile_Robot_-_Parametric_-_Small.jpg|thumb|150px|Mobile Robot|right]]

The goal of this project was to create a small differential drive mobile robot that would act as a low cost replacement for the popular E-Puck Robot. The robot uses hybrid stepper motors to allow it to track its position through odometry, has a laser cut acrylic chassis for easy replication and replacement, and a 1500 mAh, 13.2V battery pack for long run time. The robot also uses the NU32 board for its control logic and a XBee chip for communication.

 

=== [[Ferrofluid Art Display]] ===

[[Image:Persistence of Vison Display|thumb|150px|Place holder text for caption .|right]]

A little blurb about our Ferrofluid Art Display will go here. Just a few sentences talking about blah blah lkasjdfal hfalsdjh.

 

=== [[Can Launching Fridge]] ===

[[Image:27_Fridge.jpg|thumb|150px|Project photo caption.|right]]

The goal of the can launching fridge was to create a fridge that would, when initiated by either a remote control or a wired push button, automatically load, aim, and fire a can to multiple predetermined locations. The fridge uses a combination of stepper motors, a DC motor, and solenoids to create the ultimate mix of convenience, fun, and refreshment.

 

=== [[High Speed Motor Control]] ===

[[Image:2dofArmSetUp.jpg|thumb|150px|Project photo caption.|right]]
The project suggested was to design a system for high speed motor control using the PIC 32. To demonstrate the motor control, a two degree of freedom (2-DOF) parallelogram robot arm was designed to follow paths specified in a MATLAB gui.

 

=== [[Variable Frequency Electrosense]] ===

[[Image:TR_JP_PP-sensor.jpg|thumb|150px|Variable Frequency Electrosense|right]]

Our objective was to build upon existing research being done at Northwestern utilizing Electrosense technology by testing if information can be derived from varying the emitter frequency. We sought to send sinusoidal waves at discrete frequencies between 100 Hz and 10 kHz and to read in the sensed wave using a PIC 32’s ADC. We then sent the gathered information to a PC for plotting and analysis. By mounting the sensor on a one dimensional linear actuator we are able to gather additional data about objects and perform object detection and identification algorithms. While our initial results have revealed exciting trends, farther research is necessary before any significant conclusions can be made. A [http://www.youtube.com/watch?v=PJY097L2m1M video] of the project is available on YouTube.

 

=== [[Remote Controlled Wiitar]] ===

[[Image:Wiitar.jpg|thumb|150px|Guitar Controlled by a wiimote: The Wiitar!|right]]
This project uses an array of solenoids to depress stings on the neck of a guitar. A motor over the strings of the guitar turns an arm which strums the instrument, playing the chord depressed by the solenoids. The system is controlled by a Wii Remote.

 

=== [[6-DOF PPOD]] ===

[[Image:Jd-cr-Assembly.jpg|thumb|150px|Project photo caption.|right]]
The PPOD-mini is a miniaturized version of the Programmable Part-feeding Oscillatory Device ([http://lims.mech.northwestern.edu/projects/frictioninducedforcefields/index.htm PPOD]) found in the Laboratory for Intelligent Mechanical Systems (LIMS).

 

=== [[Butterfly Rolling Manipulation]] ===
[[Image:Butterflyteampic.jpg|right|upright=1.3|thumb|Butterfly Project at Mechatronics Fair]]
The Butterfly emulates contact juggling by the stabilization of dynamic rolling. The apparatus rolls a cylinder by rotating the "hand" using a specific trajectory and is able to move the cylinder from one side to the other without losing contact. A video of the Butterfly captured in high speed can be found [http://www.youtube.com/watch?v=dtYv3qNz_LI here].

 

=== [[Haptic Gaming System]] ===

[[Image:Haptikos.jpg|thumb|150px|Haptic Robot.|right]]

An interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor by moving the red joystick. Two games were created to test the feedback system. The first is a side-scroller in which you avoid hitting moving blocks. The second involves feeling out the virtual shape with nothing other than a blue position dot and a blank screen.

 

== ME 333 Final Projects 2009 ==

=== [[Mozart's Right Hand]] ===
[[Image:mrh_box.JPG|thumb|150px|Mozart's Right Hand|right]]
Mozart's Right Hand is a musical instrument capable of playing two full octaves of the [http://en.wikipedia.org/wiki/Diatonic_scale Diatonic Scale.] The user wears a glove on his right hand and uses motions of the hand and fingers to create different notes that are played with a speaker. The pitch of the note is controlled by the orientation of the user's hand as he rotates it ether from the wrist, the elbow, or the shoulder. The LCD on the front of the box tells the user the pitch that corresponds to his or her current hand orientation. When the user touches together his thumb and index finger, the speaker plays the tone. A [http://www.youtube.com/watch?v=vec-W4QeHQU video] of Mozart's Right Hand in action is available on YouTube.

'''Chosen the OUTSTANDING PROJECT by the students of ME 333.'''

 

=== [[Persistence-of-Vision Display]] ===
[[Image:Persistence of Vison Display|right|thumb|150px]]
This is a fully customizable display implemented using the concept of Persistence of Vision. User-specified images (and even moving images) were displayed by rotating a column of LEDs at speeds faster than 300rpm. Each individual LED was modeled as a row of pixels. Conversely, the rotational position of the panel of LEDs represented the pixel columns of the display; the time interval and rotational speed determined the width of the pixel columns.

 

=== [[Rock Paper Scissors Machine]] ===
[[Image:rps whole thing.JPG|thumb|150px|Rock Paper Scissors Machine|right]]
A machine that will play a fully functioning, intuitive game of [http://en.wikipedia.org/wiki/Rock-paper-scissors Rock/Paper/Scissors] (abbreviated as RPS) with a user. The machine is represented by a human-like hand, capable of seperate and independant wrist, arm, finger and thumb motion. The players' hand goes into a glove equipped with flex sensors, which wirelessly transmits data to the machine based on what the player chose. The machine then reads this data, randomly chooses a throw of its own, and displays what the machine threw, what the human threw, total win/loss/tie info, and winner/loser both on an [http://en.wikipedia.org/wiki/Lcd LCD] screen and in the form of a thumbs up/down/side motion. Video of the machine in action can be found [http://www.youtube.com/watch?v=xbLNBSTTrcE here.]
 

=== [[Three-speaker Chladni Patterns]] ===
[[Image:chladni_660hz|right|thumb|150px]]
This project uses three speakers to generate shapes on a circular aluminum plate depending on which frequency the speakers are playing at. Once the speakers hit a resonant frequency of the plate, salt migrates to the nodes (zero amplitude) regions of the plate to form distinct patterns.
 

=== [[Basketball]] ===
[[Image:Mechatronics2009Bball|right|thumb|150px]]
This project consists of a throwing arm propelled by a Pittman motor is mounted on a turntable and throws the ball into the "hoop." The hoop is wrapped in reflective tape and an IR emitter, receiver pair is used to sense where the IR is reflected most (the hoop with highly reflective tape). An ultrasonic sensor then pings the hoop for the distance of the hoop. With this information, the arm is able to "make a basket." A video can be found [http://www.youtube.com/watch?v=Y466dzP-qiY here].
 

=== [[Robot Drummer]] ===
[[Image:Robot_Drummer.jpg|thumb|400pix|right|Robot Drummer]]
The Robot Drummer is a device that demonstrates high-speed motor control by being able to drum when given commands. Through an RS232 cable, Matlab sends commands to a "master" PIC. The master then sends the commands to two "slave" PICs through I2C communication. The slaves take the commands and implement PID control of the motors.
 

=== [[Automated Fish Refuge]] ===
[[Image:Entire Fish Refuge|right|thumb|200px]]
The automated fish refuge allows for the controlled movement of a fish refuge with the goal of recording specific behavior. The mechanical design is completely adjustable and allows adjustable degrees of oscillating movement and orientation of the refuge. The program is primarily in MATLAB for ease of use and the velocity profile can be a sine, square, triangle, or any function that the user inputs. [http://www.youtube.com/watch?v=wGOKujMhN88 Check out the video!]

 

=== [[Marionette]] ===
[[Image: MarionettePicForIntro.JPG|right|thumb]] The Marionette Project focused on using RC Servos to make a puppet that would do a dance with the press of a button. There were 5 different dances programmed for the marionette, showcasing different styles of movement. The movement had 2 degrees of freedom thanks to using 5 bar linkages and 2 RC servos for each arm. Two more RC Servos were used on the back of the marionette to create the appearance of leg movement. The movements included a Hula dance, Jumping Jacks, and even some moves right out of Saturday Night Fever.

 

=== [[Monkeybot]] ===
[[Image:monkeybot_pic|thumb|right|200px|Monkeybot]]
The monkeybot is a swinging robot capable of moving side to side and climbing. It consists of a two link, double pendulum system with an electro-magnet on each end. At the pivot is a DC motor, which provides an input torque and allows the swinging system to gain energy and climb. Check out the video of the monkeybot climbing [http://www.youtube.com/watch?v=TA2VcH_GDJ0 here] and a later brachiation video [http://www.youtube.com/watch?v=0hfwJEVQyeQ&feature=related here].
 

=== [[PPOD-mini: 6-DOF Shaker]] ===
[[Image:PPOD_mini.JPG|thumb|200x200 px|right|PPOD-mini 6-DOF Shaker]]
The PPOD-mini is a miniaturized version of the Programmable Part-feeding Oscillatory Device ([http://lims.mech.northwestern.edu/projects/frictioninducedforcefields/index.htm PPOD]) found in the Laboratory for Intelligent Mechanical Systems (LIMS) at Northwestern. The PPOD-mini utilizes six speakers that act like actuators. The speakers are connected to a acrylic plate via flexures of tygon and iron. In its current implementation, the phase of the speakers can be controlled independently, giving the device six degrees of freedom. The movement of objects placed on the acrylic plate can be controlled by changing the phases of the speakers.

 

=== [[Automated Xylophone]] ===
[[Image:AutomatedXylophonePicture1.jpg|thumb|200x200 px|right|Automated Xylophone]]
The Automated Xylophone controls several solenoids which hit various pitches on an actual xylophone based on the note selected. The device has two main modes: using the keypad, a user can choose to either play notes in real time or store songs to be played back later. A video of the Automated Xylophone playing in real time mode can be found [http://www.youtube.com/watch?v=_ubpAEyq9kg here].

 

=== [[Vision-based Cannon]] ===
[[Image:SM_Gun_Camera_PIC_Setup.JPG|thumb|200x200 px|right|Vision-based Cannon]]
This project uses a webcam and Matlab to analyze an image and direct a modified USB Missile Launcher to fire at targets found in the image.

 

== ME 333 Final Projects 2008 ==

=== [[IR Tracker]] ===

[[Image:IR_Tracker_Main.jpg|right|thumb|200px]]

The IR Tracker (aka "Spot") is a device that follows a moving infrared light. It continuously detects the position of an infrared emitter in two axes, and then tracks the emitter with a laser. [[Media:MT_MS_AZ_TrackerVideo.mp4|See Spot Run.]]

'''Chosen the OUTSTANDING PROJECT by the students of ME 333.'''

 

=== [[Robot Snake]] ===
[[Image:HLSSnakeMain.jpg|right|thumb|200px]]

This remote control robotic snake uses servo motors with a traveling sine wave motion profile to mimic serpentine motion. The robotic snake is capable of moving forward, left, right and in reverse.

[http://www.youtube.com/watch?v=r_GOOFLnI6w Video of the robot snake]

Featured on [http://blog.makezine.com/archive/2009/03/well_documented_robotic_snake.html Makezine.com].
 

=== [[Programmable Stiffness Joint]] ===

[[Image:SteelToePic2.jpg|thumb|200px|The 'Steel Toe' programmable stiffness joint|right]]

The Programmable Stiffness Joint varies rotational stiffness as desired by the user. It is the first step in modeling the mechanical impedance of the human ankle joint (both stiffness and damping) for the purpose of determining the respective breakdown of the two properties over the gait cycle.

 

=== [[Magnetic based sample purification]] ===

 

=== [[Continuously Variable Transmission]] ===

[[image:CVT_system.JPG|thumb|200px]]

This prototype is a proof of concept model of a variable ratio transmission to be implemented in the 2008-2009 Formula SAE competition vehicle. The gear ratio is determined by the distances between the pulley halves which are controllable electronically.

 

=== [[Granular Flow Rotating Sphere]] ===
[[Image:Team-21-main-picture.JPG|right|thumb|200px]]
This device will be used to study the granular flow of particles within a rotating sphere. The sphere is filled with grains of varying size and then rotated about two different axes according to a series of position and angular velocity inputs.

 

=== [[Vibratory Clock]] ===

[[Image:Vibratory_Clock.jpg|right|thumb|Vibratory Clock|200px]]

The Vibratory Clock allows a small object to act as an hour "hand" on a horizontal circular platform that is actuated from underneath by three speakers. The object slides around the circular platform, impelled by friction forces due to the vibration. [http://www.youtube.com/watch?v=KhgTNCfdwZw Check it out!]

 

=== [[WiiMouse]] ===

[[Image:HPIM1027.jpg|right|thumb|200px]]

The WiiMouse is a handheld remote that can be used to move a cursor on a windows-based PC, via accelerometer input captured through device movement.

 

=== [[Intelligent Oscillation Controller]] ===

[[image:ME333_learning_oscillator.jpg|thumb|200px]]

This device "learns" a forcing function that is applied to a spring and mass system to match an arbitrary, periodic acceleration profile.

 

=== [[Baseball]] ===

[[Image:Baseball_Playfield.jpg|Sweet Baseball Game|right|thumb|200px]]

An interactive baseball game inspired by pinball, featuring pitching, batting, light up bases and a scoreboard to keep track of the game.

 

=== [[Ball Balancing Challenge]] ===

[[Image:Ballbalancechallenge.JPG|right|thumb|200px]]

An interactive game involving ball balancing on a touchscreen with touchscreen feedback and joystick action.

Differential Drive Mobile Robot

2010-03-15T02:55:30Z

JakeWare: /* Graphical User Interface */