How you can help
We are a diverse group of passionate students who are driven by imagination and creativity. And we all have one thing in common — We love and enjoy building robots! But in order to do so, we need your help so we can continue to provide this collaborative space.
If you would like to support and help us, please donate using this link: Give to WSU Robotics Club. If the donation is intended for a specific project, please write it under comments. Your donation will be used to buy the parts necessary to build robots. However small the amount is, your donation will have a significant impact to all members of the club. Also, significant donations will have their logo and name featured in our website's Sponsors page.
For other form of gifts or donations, please email us at email@example.com.
by Ryan Summers
Over the course of winter break, I finally got a chance to work a bit on our beer-pong robot. Our parts finally came in and I figured there was nothing better to work on with my newfound free time. Our mechanical engineers created a small mock set-up for the electrical team to work on and I decided to hook our motors up to it!
This gave me an excellent platform to start working on. I hooked up our H bridge motor driver and started looking through some documentation on the controller. I quickly realized that my original plan of using a PIC microcontroller would no longer work effectively in the short term, as they supply 3.3V logic and the controller works off 5V logic. Instead, I decided to switch over to an AVR microcontroller to make use of the 5V logic before I could create a board to level shift the signals off the PIC board. This would come to have much larger implications than I originally expected, but I’ll get to that later. To program the microcontroller, I used the SUBLIBinal library that James Irwin and I developed for the Robosub club. Originally this code was developed for PIC microcontrollers, but we intended to port it over to AVR. This project forced me to finish the port that I was conducting, and the library allowed me to extremely quickly implement the microcontroller functionality without many hang-ups.
I quickly wired together the microcontroller to the motor driver on a breadboard and began writing some code. I got the initial microcontroller code to get the motors spinning, but the set up was far from perfect. I really needed a method to control the motor speeds. This meant that the microcontroller needed to communicate with the computer in some way, so I decided to implement a UART interface. After buying a UART-serial converter and writing up some serial programming code on the computer side, I got an efficient line of communication going so that the computer and the microcontroller could exchange information. However, this set up had quite a few issues with it: 1) The serial interface was through the command line and was extremely difficult to use effectively. 2) It would often hang when attempting to read due to blocking calls, and 3) the motors often became stuck on set-up due to changes in friction and would stop rotating – even when operating at the same PWM duty cycle. Additionally, there was no logical way to specify motor speeds besides duty cycle percentages. To combat the issue of friction and to create an effective way to communicate, I decided to implement a PID feedback control system.
We had ordered some small magnets and some hall-effect sensors for just this purpose, but I had never really worked with PID controllers before. I set up the hall-effect sensors close to the wheels and taped on the magnets to generate an interrupt to the microcontroller whenever they passed by. This allowed me to do some simple math on the data to provide an RPM value to the microcontroller. Now, I could send the microcontroller a desired RPM and it would have a value for its current RPMs as well. The next step was to implement some form of control system so that the microcontroller could dynamically adjust it’s PWM duty cycle to achieve it’s desired RPMs. After doing a small amount of research, I realized that implementing a PID controller within a microcontroller was actually quite a simple task! By storing just a bit of previous state information, the microcontroller can periodically generate an update to the PWM duty cycle through the feedback from the hall-effect sensors. After tinkering around with the parameters on the PID controller, I managed to find some rough values that were giving me back consistently held RPMs.
Now that the issue of logical communication and a control system had been solved, I knew that I needed to fix the computer-side interface. I had done some previous work with Qt for GUIs with the Robosub club, so I decided that creating some form of GUI would be the easiest way to interface with the microcontroller. This way, I could update the current RPMs of the microcontroller and set goal values all in real-time. However, this didn’t quite address the issue of the serial port holding application execution. After some thought, I realized I could use a thread for reading and writing to the serial port, and then run the GUI through a separate application. Through the course of a day, I wrote up a small GUI to display information on the screen so that anyone can set the goals easily. Below is the GUI after a number of improvements and iterations!
(Note: ‘RPM Setting’ should be ‘Duty Cycle Setting’ above – it’s still quite rough!)
Now, we have set up an interface for the computer science team to develop a computer-side application to control the motors. This allows us to move to our next step of the project to create an application that can start using visual feedback to adjust the shots that it takes. It’s going to be exciting to see where this project goes in the next few weeks!
Update: Due to some immense errors with the ATMega chip causing shutdowns and periodic reboots, I decided to switch over hardware to the PIC32MX250F128B. The library we are using is much more rigorously tested on this chip and we have more available debugging tools for correcting code errors. Below is a 3D model of the new board that has been ordered for interfacing with the motor controller!
75 students from different majors including Computer Science, Computer Engineering, Electrical Engineering, Mechanical Engineering, and Material Science Engineering, participated the 1st Hardware Hackathon during November 14-15, 2015 held in Intelligent Robot Learning Laboratory and Frank Innovation Zone.
Robotics Club was one of the co-organizers of this event. To view this year’s winners, please visit the Hardware Hackathon’s website.
Below are few of the pictures taken during the event. For more pictures, visit the event’s Facebook page.
by Brandon Townsend
The Combat Robot Project is currently in the final prototyping stage of the wedge-bot. As of now, we are designing the belt-drive system for the wheels and waiting for parts to come in. We have decided to use existing pieces of scrap-extruded aluminum and steel plating to fabricate the beta frame. However, the final frame will have ⅛-in aluminum plates for armor in order to keep the weight within the required limitations. For the final body of the wedge-bot, we will most likely have it fabricated by a newly found resource. We are planning to have only part of the team carry out the above plan and have the other members of our team begin production on the saw-bot for the sake of efficiency.
by Bryce Johnson
The second half of the semester was spent completing construction of the hand as well as working on the control of the hand. Currently the hand is completely built and has basic movement capabilities such as open and closing and basic thumb movement. We have started modeling the hand in CAD software in order to create a separate hand in the future with additional improvements we feel are necessary to the existing design. We have also researched possible EEG sensor configurations as well as funding opportunities for these sensors.
Next semester we plan to continue working on the control system for the hand. We would like the hand to have independent articulation with each finger. Over the course of the spring semester we propose to look at two separate user inputs for hand movement: a mimicking glove design and EEG sensors.
The two teams started planning and designing early in the semester on what types of pong launcher to build. Using SolidWorks, ME students Christian Ziruk (Team 1) and Jessie Bryant (Team B) build CAD designs for the pong launchers. Both teams came up with pretty similar approaches of using spinning motors that is similar to a tennis ball launcher. What differs is Team 1, will use only one motor while Team B will use two. The videos below will show a prototype of Team B’s pong launcher.
While the ME’s were busy working on the design, the CS members worked on how to interface with an XBox controller which will be used to control our robot in the 1st Phase of this project. Then they proceeded on learning how to serially communicate with a microcontroller using Python. Additionally, the CS team had some discussions on how to frame vision processing for the robot’s autonomy once we get everything working. This includes how to detect the ping pong ball especially when it bounces.
The EE’s and CpE’s at their end, worked closely with the ME’s to come up with a list of electrical and mechanical parts that will be used to build the robot. However, in order to minimize the shipping cost, we had to ensure both teams has a complete parts list, which has costs us some valuable work time.
We also had to write a proposal for this project to secure a sponsorship for financial support from WSU IEEE Student Chapter which we successfully were granted, and we thank the organization for their benevolence.
Time wasn’t really in our side this semester as most of us were also co-organizers and volunteers for the 1st Hardware Hackathon. And a lot of our members are also members of the Palouse RoboSub Club.
However, on a positive note, we have ordered and received all the parts we need to build the pong launcher. This will allow our EE’s to start building the circuits and programming the microcontrollers on our first Robotics Club meeting next semester. While the CS members will have to wait for the ME’s and EE’s to get the structure built, the CS members will continue pursuing early next semester on solving the vision problems in order for our robot to be autonomous. We will also help the EE’s in coding the microcontrollers.
Below are videos of Team B’s pong launcher prototype. A shout out to our mechanical engineering members: Jessie Bryant and Vitaliy Kubay for working on their spare times in order to build a physical prototype before our last Robotics Club meeting. And we also would like to thank the Frank Innovation Zone for allowing us to use their equipments to build the frames for the launcher.
by Tucker Stone
The Mars Rover team spent the majority of the Fall 2015 semester working on our proposal to gain admission into the NASA Robo-Ops competition. The combined effort of our team, although admirable, ultimately was not enough to be one of the selected teams to gain entry in to the 2016 competition.
Although our ultimate goal of being entered into next year’s competition was not achieved, the team continued to work hard towards the advancement of the rover’s technical capabilities. The programming team built new code to support the robotic arm, as well as integrating the independent six-wheel drive motors.
While the programming team continued to advance the rover’s capability from a coding aspect, the mechanical team continues to struggle modifying the rover’s current design into a working system. Largely a result of the design completed in previous semesters, the team has had to spend considerable amounts of time modifying and redesigning systems that in design seem feasible but in reality do not operate as intended.
By: Marcus Blaisdell
This semester, our objectives were to transfer the existing vision system from Python to C++. Vitaly has ported the majority of the OpenCV code to C++ and we can use it to detect different contrasts. We have purchased a Kinect camera and modified it to use standard USB and have it running on a PC. Marcus has learned how to write C++ code to write to the serial port to get the C++ programs to control the Arduino microsontroller that is controlling the arm. We are going to focus on getting C++ OpenCV to recognize shapes and then improve that to recognize chess pieces.
The featured image is a selfie taken from the functioning Kinect of Marcus, Conner, and Kily (from left to right).