This is my final project in the robotics course progression at the Rochester Institute of Technology. The project requires us to study academic robotic designs, and attempt to implement a robot that combines higher level robotic control and sensing. For my project, I am attempting to create a drawing robot that automatically detects the position of its canvas using image processing.
Detecting Edges of Objects using OpenCV
Sketch Robot: Eyeing the Competition
TigerBug is a robot design I am working on for use at RIT for swarm research and as a fundraising/education tool . I am also working on developing a simulation to put TigerBug to use. Details of my progress on the different hardware and software components of this project can be found below.
Construct Projects are things that I have worked on while employed at The Construct, the makerspace at RIT. I officially work here as a lab manager, but among my many roles, I am also a WebDev, Graphic Designer, Systems Engineer, and even a Carpenter! We’re a small space with a small budget, so many of these projects involve developing equipment and infrastructure for low costs.
Here is a list of some of the things I’ve worked on during my short time here:
In fall 2015, at my internship in Massachusetts I spent a fair amount of time learning how to design PCBs. This was a big step for me as an EE, and I was interested in trying to create one on my own. However didn’t want to make just any simple circuit (of which I have made several, out of old-fashioned pegboard and solder bridges), I wanted to find a project that could mesh with my interests in robotics. I needed a source of inspiration, and happened to find it in the middle of downtown Boston in early eptember:
The StrandBeest Project, which designs large kinetic sculptures that move due to wind pressure, held a public demonstration that I happened to catch. which was was little disappointing at first because due to the lack of wind, the mechanisms weren’t able to move themselves and were pulled along by their curators. Then I got to thinking, couldn’t I just make one of these and power it from a motor? Couldn’t I create a board that controls the motors and allows me to remotely control my own little strandbeest-robot? They’re pretty slow…maybe I can come up with a way to make them run faster? So from that, I came up with Bugbeest:
Well, it was a start. This was my rough concept after some fiddling around with different mechanisms over the next few days. I was aiming to create something that, Like a strandbeest, could manipulate its limbs in complex ways, while being powered from a single source. The design uses a cam on a rotating pulley to produce the leg motion. this cam is set at a slight angle relative to the ground plane, and fixed from pivoting vertically. this produces a rotation around the pivot point, and a translation in and out. By connecting linkages in a certain way I was able to get a natural leg movement out of the system. I was aiming for a six-legged layout, as the hexapod robot form factor is notorious for requiring a large number of servos to control properly, which makes them prohibitively expensive and prone to malfunction. I believed that a simplified robot chassis could prove to be useful here. Not doubting my CAD abilities, I created a more polished and fully formed BugBeest, and it worked!
The models were created and rendered in Inventor. I had some experience with Inventor’s rendering tools prior to this project, but this was the first time I had attempted to properly render video with the software. It works very smoothly and I plan to use it much more in the future.
The next step was to create a real version of BugBeest, to prove the design and perform some powered tests. the bot had been designed with 3D printing in mind, and creating the main body was not too difficult (but was very tedious, it took 21 hours to print!).
I ran into much more trouble on the pulleys. I decided to create custom loops of belt to control each side of the robot with a single motor (why one motor on either side? I only had 2 and they cost more than I was willing to spend on the project at the time), and had settled on gt2 2mm pitch belt, which is cheap and commonly available. However, my 3d-printed pulleys weren’t fitting the belts; I hadn’t taken the flex of the belt into account when creating the tooth profile in CAD. This was fixed using some very un-scientific trial and error designs. In the end, the belt fit perfectly over the pulley.
So, does the design work? well, mostly:
It functions as I expected, but the legs will quickly get out of sync as there are varying levels of friction in the belts and leg joints. The belt in particular cause a lot of headaches for this build, and future revisions of Bugbeest will likely forgoe this part, using a motor to actuate each leg. There are several other reasons to do this as well, as I explain below.
Either way, I needed a better way to control the bot than my bench power supply and a long cable. I could have just thrown an arduino and some motor shields inside the body and stopped there, but I’m building this bot to learn, not just for the fun of it! So, I learned Eagle CAD, and made myself a robot control board:
The board is build around the Atmega328p microcontroller, the TI DRV8802 dual H-bridge motor driver.,and the Nordic NRF24L01 radio transciever. these three chips do all of the crunt work to create a 2-motor, wireless robot. I also included a 12V boost converter, two ATTINY85 microcontrollers, a USB/UART converter for serial programming, and some reset control/voltage monitoring circuitry.
because this was the my first go at designing a PCB, I was a bit wary that I had made a design mistake. So, to ensure the design would work before ordering the boards from a manufacturer, I laid out the design on a breadboard:
there were several parts of the design that I figured would need to be tested. the biggest one being the two ATTINY microcontrollers I mentioned earlier. the motors that I chose to use for this project (some gearmotor made by Faulhaber, suffice to say they are pretty nice but very expensive) include a quadrature encoder, which outputs two offset square waves when rotating. These are very high resolution (over 500 “ticks” per rotation), and would bog down the main microcontroller with constant interrupts to read the new motor positions. the ATTINYs are used instead of these, and store the motor position and number of rotations in registers that the main ATMEGA can access over the I2C bus.
Once I was confident the board would work, I sent the design files to the great folks at OSHpark to make the PCB. I then assembled the components on the board, and we had a working bot!
…wait, where’s the video of it walking around?
well, there isn’t one. the Hardware of Bugbeest ended up being very hard to work with, and to make a long story short it requires a redesign. At this point I was finished with my internship and returning to classes, so I didn’t (and still don’t 😛 ) have time to improve the design. What a downer ending, right?
When the eventual Version 2 will appear, I can’t say right now. but I do know what improvements it will include:
I am a member of a club at RIT, which mentors FIRST robotics teams and supports the FIRST organization however we can in the Rochester area. One way we spread awareness is by hosting an exhibit at Imagine RIT, an annual creativity festival were different groups on campus show off what they research/study/build to the general public. it’s RIT’s largest event by far, and quite a madhouse to be honest!
Our club hosts a booth where several local robotics teams show off their student’s creations, and we typically had a small area with some simple wheeled robots for kids to fool around with. in 2015 however, we decided those robots needed an upgrade. So we came up with Ping Pong Panic! , a miniature FRC game using ping pong balls.
For this project, me and my team members made use of The Construct@RIT, our student-run makerspace (which I happen to be a member of). We used the tools there to create the PCBs, the field, and many of the custom parts for the robots. We used a COTS robot base kit from ServoCity and worked from there to create some easy- to use robot designs.
The Bots were created using Arduino Pro Minis for ease of programming and cost-effectiveness (we managed to keep this project within our budget of $250). They used a Nordic Semiconductor NRF24L01 2.4Ghz wireless transciever to communicate between each robot and the “field” arduino. this uC is sent commands from a laptop running a java program that reads data from four game controllers.
I didn’t get any video of the robots being used at Imagine (i was helping to run 2 booths, so I was in a perpetual sprint between those locations), but I did get some video of us testing them the day before.
The game was rushed to completion the night before the event, so things were a little shakey, but it workded! Kids never see the flaws in projects like these and they had a blast driving the robots around. We intend to build upon these and make them even better for Imagine RIT this year.
Autoboat was inspired by me being disappointed in myself. A bit of an odd source of inspiration, but in a way that was a big motivational help.
I entered summer break after my sophomore year at RIT feeling pretty discouraged after not having the determination to find a summer internship. I had always struggled at employing myself, but by this point I needed to get to work or risk falling behind in school. with less than stellar grades and no real work experience I felt doomed to fall into the endless loop of job application rejections. I realized that I needed a project that would stick out on my resume, and also teach me things about designing a robotic system that I felt my classes had not yet covered. With that plan in mind, I found an old model sailboat in my basement and decided to make it autonomous. I had no prior experience with creating autonomous robots, and even less experience with designing one from scratch. so I started by working on what I knew best: improving the mechanical components.
The original sailboat was designed to be raced and was not easy to cram full of sensors and servos, so I started by modifying the hull. Adding a larger hatch made the later modifications to Autoboat much simpler. I also replaced the beautifully dated blue and white paint job with something a little better.
The next step was to plan out the internals of Autoboat. To do this, I reverse-engineered the hull components in Autodesk Inventor, and started designing the components that would allow the system to perform in a wide range of wind and wave conditions. The design of this portion of boat has been the hardest part of the project so far, and has had 2 major revisions (the 3rd is still in the design phase). I called the main component the Sail Adjust Module or SAM, since 90% of it’s function was to ensure the lines that went out to the sails would operate without tangling or unspooling. The small vertical servos were intended to be used for coiling and uncoiling the lines as they were adjusted. this worked to some degree but ultimately the design was flawed for several reasons. I go into more detail in the project report at the end of this page.
The next step in the design process was to design a mechanical unit that could give me greater control over the two outputs of the system, mainly the sails and the rudder. This was Autoboat’s first 3d-printed part, and far from its last as I added more and more sensors.
Autoboat introduced me to many more sensors and signal processing designs that I had not experienced before, including working with an IMU (innertial Measurement device) to find the boat’s position in 3D space. one of my favorite components, the magnetic encoder-based wind direction sensor, was also created at this time.
So, why isn’t Autoboat finished? there have been long periods where a variety of issues have kept me from being able to work on it. Between the start of the project and now, I’ve worked at 2 different engineering companies, joined several clubs at school, and started several other robotics projects. Someday I may return to the project, but I believe that I accomplished what I set out to achieve either way.
Benja! 