Category Archives: Intel-Cornell Cup

All blog posts related to the Intel-Cornell Cup project

Fall Semester Wrap-up

Fall semester has been a busy one for the robotics club! We kicked off our two projects for the year in September: the Firefighting Robot Competition, and the Intel Cornell Cup.

For the Firefighting Robot Competition, club members are building self-driving robots that can navigate a maze using intelligent sensor systems in order to find a candle and put it out, all as quickly as possible. This semester, we did a few different workshops where we rigged up robot chassis to drive along walls, designed parts in CAD, and brainstormed different robot designs for the competition in April. At the start of next semester, we will pick up where we’ve left off and put together our robots for the main competition. Wish us luck!

Here are some photos of the Firefighting group at work:

The Intel Cornell Cup group have begun working on a drone to assist search and rescue teams in the wake of an earthquake or other such natural disaster. The drone will autonomously search an area for people in need of help and report their locations back to the team. This should be a useful tool in determining where a rescue team’s efforts are most needed so that teams can be more efficient. So far, we have run a few different tests on the drone and on thermal cameras to assess how well they will perform for our particular application. We made it into the semi-finals of the competition in December, and are preparing for our presentation in January!

Here’s a photo of the ICC team this year:

ICC Team 2016

That’s a quick look at what we’ve been up to this semester. If you like working with robots, consider coming to our weekly meetings! No experience necessary – learning and teaching are a big part of what we do. Thanks for reading!

Custom Servo library

Last night I wrote up a wrapper for I2C communication with our 2 RMCS-2203 servos. We also set up a github repository which will host and version-control all of our code. I also put our electronics schematics in there. Here’s a link to the repository so you can peek at what I’ve written:

My library appears in the “main_sketch” folder and consists of the RMCS2203.h and .cpp files.

I’m pretty proud of the library. It allows you to set and get every parameter described in the I2C section of the datasheet (which I’ve hosted here:

You create the RMCS2203 object like so:

RMCS2203 myMotor;

And in setup() you attach the motor to a particular I2C address:


Then you should probably set the servo’s control system to default gains, since these can get set improperly when powering off the motors:


Simple as that. I have yet to write any code to move the smaller servo, but I should most likely be able to use the Servo library packaged with the Arduino IDE, so there’s not much work to do there.

Final Iteration of Shield

So I continued work on the shield and changed quite a few things from the last design. First, I decided to move the relays off board and connect them to the power supply with low gauge wire instead of routing power through the board, as I was scared of overheating the board with high current draw (the linear actuator goes up to about 5A at max draw). There are now two additional 2-input screw terminals, one to connect the coil from each relay. This also reduces the size of the board substantially.

I’ve added a D-sub 15 pin connector plug in our joystick with all necessary voltage division and pull-up resistors on board. Initially I forgot to include the joystick interface in my design, but that was quickly fixed.

I also widened the small traces because of the way we are fabricating the board. We didn’t have enough time to get the board professionally fabricated (I tend to order from OSH Park, but their turnaround time is 12 days!). Instead, we used an Othermill at the Makerspace in Tufts’ Center for Engineering Education and Outreach. The Othermill is a small milling machine which can make single-layer circuit boards from a copper sheet. We used two single-layer copper sheets to do both of the layers of our board. This involved mirroring the board so that the copper would eventually be on the underside of the board, for ease of soldering in through-hole components.

This meant we could get our board in a day as opposed to two weeks.

The final board layout and schematic are shown below:schematic BOARD

The gripper in action!

Take a look at our gripper doing its thing:

Some notes from testing:

Water is much more effective at creating negative pressure than air, since it’s non compressible. We get much better grip while also moving the syringe less distance, meaning that the linear actuator won’t have to expend very much energy to get the gripper to become rigid.

In addition, a water based system means this gripper could potentially work in space. Overall, the water is beneficial in just about every way. We just need to be mindful about how we keep our electronics safe from potential leakages.


Some notes about the design:

We use glass beads in the gripper because they are waterproof, as compared with the traditional universal gripping material, coffee, which would dissolve in water over time.

We use commonplace 11in latex balloons to hold the beads. The balloon is clamped to a tube with a filter on the end to prevent the beads from flowing back into the tubing. The tubing runs to a syringe which will eventually be actuated by a linear actuator. The whole system is filled with water.

Designing the Electronics

Lately I’ve been busy designing a shield for the Intel Galileo which will interface all of our actuators. This includes the linear actuator and three servos. They are all controlled in different ways, all of which is handled by my board.

The 2 larger servos, the RMCS-2203’s, are powered from a 12V source (not routed through the board, since there is high current draw) and controlled via I2C. It is also often necessary to communicate with these servos over a serial connection (which basically opens up a command line interface for setting certain servo settings). It’s pretty cool and advanced for a simple motor. Anyway, I want to enable all of these communication channels between the Galileo and each motor. I reserve pins on the Galileo for software serial, 2 for each motor (RX and TX). These are pins 2, 3, 4, and 5. Then I link the SDA and SCL pins out of the Galileo to each motor. I use JST headers to as the motor plugs.

The smaller servo is controller via a simple PWM signal (like most servos) and is powered from a 9V regulator onboard which receives 12V from the 12V source as input. Pin 9 is reserved as the small servo control pin.

Lastly, the linear actuator is controlled by dropping 12V across it in either direction. Reversing the polarity will make it change directions. For this reason, we need a setup which uses two SPDT relays. This will allow the Galileo to reverse the polarity of the linear actuator while also remaining isolated from its power supply. I looked up a schematic for a single SPDT relay from Sparkfun for inspiration:

Powering the linear actuator through the board is tricky, since it can draw up to 7 amps. I used this calculator:

and found that 7A with 1 oz/ft^2 of copper thickness requires a trace width of 451 mil, which is enormous. I can’t quite make that, so I’m hoping 200 will do. I only expect bursts of 7A so it should be okay.

I’m continuing to work on this, but here is my schematic so far:



And here’s the current layout of the board. Notice the thickness of the traces around the relays:



Also the thick blue traces on the right appear to be connected, but htat is merely due to the small resolution of the picture. They’re isolated from each other in the actual design.

Hoping to get this shipped to us by next week!