Pmod Racing Ruler!

Aaaaand we're off!!!

Alright, so perhaps the explosion behind the racing ruler isn't real, but I don't think that detracts from its coolness.

In this Instructable I'll go through what I did to make my own little racer that automatically stops whenever it bumps into an object. You can also check out the video of what to expect out of this project.

That's right, this was inspired by the fact that I would be able to create a streamlined, light-weight racing robot that uses a ruler as its chassis. But not just any ruler -- this is actually a PCB ruler that you can solder components onto and route power to those components through the ruler itself.

I figured if I could route power through the ruler, how hard would it be to mount motors, a power source, and a breadboardable microcontroller and route power to every component in the system? Let's find out.

This project used a variety of materials. I happen to have a lot of Digilent materials on hand so I ended up using a lot of those, but did use some other pieces as well:

• 2 Digilent PCB rulers
• a PmodACL
• a PmodDHB1
• a chipKIT Cmod
• 2 DC motors and their brackets
• A pair of wheels to fit the motors
• a pair of dolly wheels
• a pen
• zipties
• electrical tape
• access to a soldering station

I'll go ahead and jump right into things to get this project running!

The first thing I did was to get the wheels setup for the racer. The motors come small screws that you can use to mount them directly onto the bracket. I oriented my motors such that the set of wires coming off of the motor (which will be used to control the motor) are directly beneath the slotted area of the bracket. (see pictures 1 and 2)

Once the motors were secured onto the bracket, I took one of my zip ties and wrapped it around the end of the motor closest to the shaft and the top of the bracket with one end of the Digilent Ruler on top. This took a couple of tries to get right and quite a bit of effort to make sure it was tight. Luckily I found that even when it was tightly "zip tied", that if everything fell apart somehow you can still get it all connected together without having to get a new zip tie.

Once we have done this for both sides, the back axle will be successfully completed!

Now we need to get the chassis portion of the racer ready to go. To do this, we will secure a second ruler perpendicular to the first ruler using zip ties. This is definitely unofficial and not terribly fancy, but it does get the job done. In terms of placement, I lined up the second ruler to be in the middle of the back axle with only a small portion (about a centimeter) of the second ruler sticking out past the back axle.

The reason for this is because I wanted enough room to mount the 9V battery without impeding on the microcontroller that will be later soldered onto the PCB ruler.

I feel that now is a good time to talk about why this PCB ruler was chosen in the first place over a breadboard or pretty much anything else. There are two main reasons for using the ruler. The first is that it is small and lightweight (much more so than a breadboard), but sturdy enough and appropriately sized for a small racer. The second reason is that you are able to both mount or solder on any necessary components directly to the ruler if you so wished. But more importantly, the Digilent ruler has power rails routed throughout the PCB so you can easily power any components mounted anywhere on the ruler with only a single contact point to the power source.

This ability to route power throughout the ruler was probably what sold me on using the ruler for a chassis; other PCB rulers exist, but I find they tend to be more of a reference than a PCB. Don't get me wrong, I love the Adafruit PCB ruler that I have, but in this case the Digilent PCB Ruler takes the cake.

Next, I attached the battery holder to the underside of the second ruler. I personally used velcro to secure the 9V battery case to the PCB ruler.

It doesn't particularly matter what sort of battery holder you use - I happened to just use a 9V battery because it provided enough power to run the motors, was within the chipKIT Cmod's accepted voltage input range, and is small enough to live on the underside of the racer without dragging along the ground or being too big or heavy for the racer.

One thing that I did make sure of was that I could easily detach the battery from the racer but not have it fall out mid-flight. I imagine the easiest way would have been to install a small switch or female jumper between the wires so that I could connect and disconnect the battery power as needed, but as you can see from the above pictures and later on in this Instructable I did not do that.

Such is the life of prototyping.

What I ended up doing next was mounting the chipKIT Cmod, the brain behind this racing ruler, onto the chassis. As a breadboardable microcontroller, the chipKIT Cmod was the ideal option to secure onto the wirewrap portion of the PCB Ruler.

There were a few things that I took into consideration before soldering on the microcontroller though. The first was that I wanted to ensure that I would be able to easily reprogram the firmware as necessary throughout the development process. This necessitated that the microUSB port that is used to program the board was at one end of the ruler in order to make it easily accessible.

The second thing was to make sure that as many signals and pins that were to be used on the microcontroller were connected directly onto the wirewrap portion of the ruler so that I could easily access them there rather than having to do any extra wiring on the side. I knew that I wanted to use the PmodACL which I figured I could plug into one of the Pmod host ports on top of the microcontroller, and the PmodDHB1 to control both of the DC motors. The PmodDHB1 uses general purpose pins to communicate with the host, so I needed to be able to find 4 available I/O pins that were ideally available on the side of the microcontroller that is connected to the wirewrap section of the board. Luckily, I found four such pins (covered later on in this Instructable).

Lastly, I wanted to make sure that the microcontroller was level on the racer and did not have any obvious possiblities of it accidentally shorting out any of it's pins. As you can see in the photos, I chose to have them microcontroller arranged such that the USB port was as close to the edge as possible, but have the set of pins that were not sticking into the ruler have their housing rest on the edge of the ruler. This kept the microcontroller level on the ruler and also avoided having it stick way off to the side on the ruler as well.

The PmodDHB1 is a dual H-Bridge module that I decided to use so that I could control both DC motors as needed. To mount the PmodDHB1 on the back axle, all I found that I needed to do was to take both sets of wires coming from the DC motors and attach them to the respective receptacles on the Pmod; this provided enough tension to hold the Pmod in place without needing any zip ties or soldering.

Naturally though, wires are still needed to be able to both power the PmodDHB1, the motors it's attached to, and to provide appropriate signals to the internal H-Bridge circuits. The GPIO signals to run the two H-Bridges (specifically the enable and direction signals) are located on pins 1 & 2 and pins 7 & 8, respectively, for motors 1 and 2, respectively. More information about how the signals are connected can be found in the PmodDHB1 reference manual. Where these GPIO signals are connected on the chipKIT Cmod is covered in the next step.

Two separate sources of power are needed for the PmodDHB1: one set is the external voltage used to power the DC motors and the second set is to power the internal chip drivers and MUXs present on the PmodDHB1.

The external motor voltage is fairly straightforward. We can connect the battery terminals (via wires on the case or otherwise) to the pair of screw terminals on the back of the Pmod nicely labeled as "VM" and "GND" for the positive power and ground from the battery, respectively. We can then later use this same set of screw terminals to route power to other components on the racer as necessary.

As for the internal chip positive power source, we need to connect whatever logic voltage we are using to either pin 6 or pin 12 on the Pmod header. The chipKIT Cmod operates at 3.3V CMOS logic, so what I ended up doing was soldering pin 6 to one of the outer circles of the "finger buttons", being careful to avoid connecting the inner button to the outer circle because the inner button is powered at the external battery voltage (9V in my case). You can always test with a multimeter to measure the resistance between the two circles after you're done soldering to confirm that you do not have 0 ohms of resistance between them. The reason for using the outer circle is because it is electrically connected to the smaller contact of the same number. We can then connect the smaller contact to pin 2 of the ICSP header which is connected to the Cmod's 3.3V source.

We do not need to worry about the ground pins (5 and 11) on this header because they already share a common ground from the external battery connection in the back of the Pmod.

The chipKIT Cmod provides the 4 GPIO (general purpose input/output) signals needed to properly control the Dual H-Bridge so that the two DC motors can be driven as desired. I knew I wanted to have the four signals be on the side of the ruler with the wirewrap section so that I can easily connect them to PmodDHB1.

Taking a look at the pinout diagram for the chipKIT Cmod, specifically at pins 21 through 40, I looked for 4 pins that were capable of performing a digital write and were not sharing a pin with the Pmod header J1. The reason for avoiding the Pmod header J1 is because that is where the PmodACL, which uses SPI to communicate, is to be located, so I did not want to have any conflicting signal pins. Ultimately, this resulted in me choosing pins 22, 26, 27, and 29 as my GPIO signals for the PmodDHB1.

To actually make the connections between the Cmod and the Pmod though, I ended up splicing some cables (to a shorter size for convenience) so that I could use the female connectors to connect to the Pmod header and soldered individual male pins to the appropriate row locations on the ruler to match the Cmod pin locations.

Remember to then solder the PIC32 pins of the Cmod to the ruler as well--I definitely forgot to do that the first time and was very confused as to why my motors were not responding to the signals coming from Cmod.

I mentioned earlier that a major factor that helped me choose the Digilent PCB ruler over other rules was the fact that I am able to route power throughout the ruler. In the case of the ruler, the positive power rail is located on both the centers of all 8 "finger buttons", the right-most two contact points on each of the Pmod ports (A, B, and C), as well as the "+" marked rail and large contact point on the right side of the ruler.

The negative power rail (typically used as the ground rail) is provide on the two contact points to the left of the two right-most points on each of the Pmod ports (A, B, and C) as well as the "-" marked rail and large contact point on the right side of the ruler.

With all of these contact points, it makes it very easy to route power from the battery in small jumps rather than a large wire that can be easily disconnected on accident.

The chipKIT Cmod has a on-board regulator that can receive outside voltages ranging from 7V to 15V, so by connecting the battery positive supply to a center button pad on the back axle, then to a center button pad on the chassis, and then connecting the Vin pin (labeled as pin 1 on the silk screen) on the Cmod to the large positive contact point, I am able to provide the positive power source directly to it. For the 0V ground connection I choose to connect the negative terminal of the battery to the ground contact point on the ICSP connector (JP2, pin 3) to provide the common ground to the Cmod.

This was probably the easiest part of the project. The PmodACL uses SPI to communicate with a host system, so all I did was confirm that one of the Pmod ports on the chipKIT Cmod used SPI, which in this case happened to be header J2, and then inserted the Pmod to the port, making sure that it's pin 1 matched with the pin 1 on the chipKIT silk screen.

But why have the PmodACL at all? The PmodACL is an accelerometer module with some built-in interrupt capabilities that you can program to trigger when a certain acceleration condition is met. I wanted this racer to be able to stop whenever it hit an object, such as wall, rather than running into a wall or corner and draining it's battery as it continues to spin it's wheels uselessly. By having the racer get a sudden change in acceleration by hitting a wall, an interrupt would be sent to the microcontroller, who would service the interrupt and tell the two DC motors to stop running.

We are now at the point where all of the electrical hardware of the racer is complete. Now, we get to take a slightly different approach and create a set of dolly wheels that nicely spin when the motors start running. I happened to find a pair of K'nex like wheels and a metal (or plastic) rod that nicely connected the two wheels together. Once I had that, I took a plastic BIC pen and cut the casing to a size where the wheel and axle combo just fit inside of it.

I decided to share a bit of the troubleshooting that I had to do while working on this project. After making the front axle, I figured that all I had to do was to put it on the front of the racer, try out a few sensitivity settings on the PmodACL until it detected the bumps correctly and then I would be good to go.

What I didn't consider is that with the wheels placed all the way at the front (with the axle being held in place with electrical tape) is that when the racer hit a wall, it would then simply attempt to drive straight up the wall and fail to do so because the wheels were so far forward. Whoops. Turns out a needed a better placement so that it did not drive up a wall, but also struck firmly enough so that the accelerometer would be triggered, telling the microcontroller to stop the motors.

It turns out pPlacing the front axle an inch behind the end of the ruler is a much better location. Not only did the racer have a solid front to get a good collision detection, but the placement also makes a lot more physical sense for the racer, at least to me.

All we have to do to get our racer roaring into action is to load the sketch onto the chipKIT Cmod. You can use MPIDE or the Arduino IDE with the chipKIT Core. You will also need the PmodACL library which you can download from the example code page of the PmodACL Resource Center. Examples on how to install a library for the Arduino IDE can be found here and a similar guide for MPIDE here.

The sketch that I used for the Pmod Racing Ruler can be found in this step in a .txt format, a .pde, and a .ino file.

A short (and admittedly not super high quality) video of the Racing Ruler can be seen here on the embedded YouTube video.

But is there more?

While seeing one way to make a super awesome racer (or at least I think it's super awesome) is all well and good, I feel that it could be even better if there was a nice video (rather than a somewhat lame one taken with my phone) to go with the project -- like the one shown in this step!

As always, feel free to ask any questions you may have, or share your thoughts in the comments below!