I have been working on converting a radio control truck into a robotic truck. It's not going to be an android (human-like) like many people associate with the word "robot", but rather I'm implementing an electronic "brain" along with some sensors and other features. I may do something like giving it the ability to store "tricks" into it's memory, but that can come later. This webpage is to document my progress as well as provide updates for anybody interested.

The plan is to use a pic16F877a microprocessor for the central control and add additional components as needed. One of the nice features of these chips is they can communicate with other PIC chips, so I can expand if necessary. I already had a programmer (a device for writing programs onto the chip) for a pic16F84a, which is an 18-pin device, but I designed and built an adapter for the pic16F877a chip, which has 40 pins, and it works wonderfully.

My remote control truck is one I got quite a few years ago at Wal-mart, with controls that are either on or off. This means it can be stopped, full-speed forward, or full-speed backward, but nothing in between. It's the same thing with the steering: left, right, or straight.

My first task is to take my remote control truck and replace all components inside to give it digital proportional control, which means it has variable speeds and steering. I bought a radio control transmitter and receiver pair designed for remote control aircraft since it has quite a few additional controls besides steering and throttle so that I can control any additional features I want to implement. Plus the new frequency will allow the truck to go much further than the cheapo circuit board it came with. I also bought a servo for steering and I'll build an electronic speed controller for the throttle. Building it myself will allow me to make better use of the main processor for speed and direction control. I'm also planning on using the landing gear switch to control headlights and taillights (which I am adding to the truck along with reverse lights). Most of the lights will be automatically controlled by the microprocessor using the sensors and current remote control input.

Today I went and tried out a few new settings. I changed the numbers so that the dimensions were a lot more accurate. Then I went and even though the extrusion rate was too much, I increased it further because it didn't seem like it was flowing together nicely. For another cube, I increased the printing temperature and it seemed to bond together better. I have a suspicion that it's reading the temperature wrong and so I may need to further increase the temp. Regarding the motor slipping on the X-Axis, I realized that was one of the motors I had not upgraded yet, so that may be one of the things I do soon so I can avoid any more layer shifting, especially since I already have the motor.

I started working on a Bill of Materials. The problem I was finding with the I3 was there were quite a few variations. I believe I have narrowed it down to the MK2S version and I need to come up with a BOM for that. I selected that one because it seems to be a good balance between ease of parts acquisition and sturdiness/features of the printer.

I regards to my current printer, I remembered something about removing a diode if you wanted to power it externally, so I did a little digging. There's a diode on the RAMPS board that if removed, requires the printer to be plugged into a computer. However, the advantage is that the USB power and the main printer power are separated. I decided to go with this since I was pretty paranoid after having the printer blow up the USB port, keyboard, and trackpad of a laptop I had used. While attempting to remove it, it seems I accidentally loosened a capacitor, so I went and pulled out a spare RAMPS board and successfully removed the diode on that.

I went ahead and plugged in the board into the printer and hooked up the wires for the hot end and heated bed and placed the first stepper motor driver into it. Then I played around with plugging various motors in until I had the first axis working correctly. I continued doing this for the other axises and extruder. Then I got the end stops plugged in and finally the temperature sensors. Each time I unplugged the printer between installing stepper motor drivers or plugging in motors so I wouldn't damage anything. I was able to get all of the functions working correctly. I went ahead and adjusted the power screws on the stepper motor drivers. While doing that, I noticed something strange. While I touched a screwdriver to the screw, if the motor was attempting to move, it would play some foreign radio station through the motor.

After everything was set up, I loaded Slic3r and entered my printer settings and decided to print a cube for testing out the dimensions. It went terribly wrong. The infill wasn't printing very good. I slowed the printing down for the inside and increased the heat. I then tried again and it was a bit better, but failed mid-print because it shifted over a few millimeters. I increased the power to the X-Axis since that was the axis it slipped on. I still have a few more things I want to try such as different filament and slowing down the speed. If that doesn't work, I may try a one of my newer how ends. It appears I can take the bowden tube holder out and it should fit right in. However, it's a little taller, so I would have less print area height-wise.

I want to make sure I can print off the printer parts for the I3 before I spend any money on the hardware, so this will be my focus. I'm quite certain I can do it if I adjust enough things.

So I went to check if I had the latest firmware and I see they now have documented the process of setting of the configuration. So I downloaded the firmware, went through step by step and finished the settings. I was able to get it to compile and upload it to the 3D printer.

One thing I realized is that with all of the extra parts I have, I don't think it would be a huge cost to build and convert it to a Reprap i3 printer. I already have an extra set of smooth rods for the i2, which are longer than I need them to be, so it would just be a matter of cutting them down. Once I get the printer working as it is, I can print off a set of the 3D parts for the i3 and I think I would mostly need some m10 threaded rod ($25 pre-cut, possibly cheaper if I do it myself) and a frame ($20) for acrylic. I think I may need to get an aluminum tray as well, which may cost a bit more. It's also possible that I can get all of the components together as a bundle from Aliexpress for a decent price, though it may take weeks to ship.

The main advantages to switching to the i3 are that it's more stable and has a bigger print area. It looks like my plan to change out the extruder and convert to a bowden style works well with the i3.I think the next step will be coming up with a bill of materials and crossing off what I already have.

Some of the stuff I have planned (and purchased already) as upgrades for my 3D printer include dual Bowden extruders. I went with the Bowden style to reduce the size and weight of the one of the fastest moving parts of the 3D printer. The momentum caused by the old extruder would literally shake the printer as it went back and forth. Another upgrade is a full aluminum heating plate for better heat distribution as well as a sheet of Kapton tape over the bed so that the item will be removable. I removed the borosilicate (pyrex) sheet of glass because when I've printed directly on it in the past, I've had the print stick so much to it that it literally took a chunk of glass when I removed it.

I went ahead and ordered an extra set of stepper motor drivers, though I may have barely enough on hand to get it working if I mix-n-match. I plan on spending some time working on the printer tonight to see what I can get working. I didn't have much time last night because my daughter had a choir concert that I attended and she did great.

I realized the most time consuming part of getting it up and running will be getting all of the settings for the firmware in place. I had an older version of the firmware and there are new options and some of the other options are now gone, so I just need to comb through everything. I had spent a little time a couple months ago at least downloading the firmware and most of the software to compile it and started plugging in some settings, but I know I have a bunch to do still.

I don't expect this week to be quite as productive as last week due to a couple of things. For one, I made a bunch of social commitments and secondly, I can't do much work on my printer at lunch time like I could on my car. I do have a show that I'm trying to finish up watching and I have about 10 more episodes. After that, I should be much more productive.

After looking at a few charts, I believe the CAN inputs are for M-CAN (though I did see a couple of sources say C-CAN so I'm not 100% certain), which is the Multimedia CAN channel that the car interfaces with the AVN (Audio/Video/Nav) unit. The next step would be to find where the wires go to it.

At lunch on Friday, I swapped the data lines for the USB port and tested them only to discover that swapping them reversed them. So I looked at some more diagrams and it appears that the one I pulled up off the internet the day before was wrong and that I had originally been correct in the color coding. So that was a wasted 20 minutes plus it'll be another 20 minutes to redo the wire swap. I guess I'm starting to learn now to test and then make the change and test again instead of change then test. So, that means I tested a bunch with everything in the correct position and the video from the camera looked pretty messed up while the USB port was connected to the radio. All I can really do is exchange the wires and try again. It looks like I may have to swap them on the adapter as well.

On Saturday, I swapped the adapter data wires and the wires in the car. I hooked everything up and just before putting it back together, I decided to test if we were getting voltage from the USB port to test with. It turns out that the pinout is reversed from what the diagram shows, meaning all I needed to do was turn the plug around and it worked fine. I also tested the Aux Port and that worked fine. So after going through all of that, I decided that rather than mess with the CAN bus for now, I would rather just have everything back together and so I went to assemble everything. It turns out there were a couple of posts on the back of the panel that goes over the stereo that were lined up for the old stereo and not the new one. I went ahead and shaved those down flat and was able to get everything together. I put the trunk back together as well.

So for my next project, I decided to start working on the 3D design of the camera adapter using OpenSCAD. This is the part I will print off on my 3D printer that will allow me to mount a camera at an angle. I got about as far as making the plate that will go against the car and the housing that the camera will sit inside. I still need to figure out some tabs for holding it into the car as well as take a few additional measurements. I ordered the stepper motor drivers since the ones that I have all seem to have bent pins or missing heatsinks and I think that's all I will need to get my 3D printer working.

I had an idea for adjusting the camera angle. I could probably make a wedge of some sort if I get my 3D printer up and running. Originally I was thinking of buying a block of plastic and cutting it to shape, but after thinking about it, I can produce exactly what I want if I get the printer up and running. It's a great motivation to work on it and simple enough that there is a relatively high chance of success. Plus I already have the correct filament in black. I would probably need to make a reverse wedge to go on the inside as well. The main potential problem I see here is that it may require too much depth for the length of the screw.

The other option I am considering is getting a different camera with a compatible plug that has a better angle. I found an aftermarket one for a Hyundai Elantra that I believe would fit in the same size of hole, but that would be an extra $25. According to Amazon, it has an tilt angle of 42 degrees from being straight out. I took a picture of my current camera and used a protractor app to approximate the angle and it appears to be around 50 degrees, so that would be a marked improvement.

A great idea I just had is that I could design something on the 3D printer that replaces the plate that snaps into the vehicle with something that puts the camera at exactly the right angle. with the camera sunk in a bit. This may take a bit of time to design, but it would probably be the most ideal result for the cost.

So laying out those options, I think trying to get my 3D printer functioning would probably be the first thing to try. If I can get it going, I may try my hand at designing something that will work exactly right. If that fails, I may try and just print some simple wedges. If that fails, then I'll go with the $25 camera. As an absolute last resort, I could get a camera that mounts above the license plate, but honestly I think I would prefer to stay with what I have now over that option.

I decided to do a comparison and found a pinout diagram for the old radio and the new radio. After comparing the pins, I can conclude several things:

  1. The AUX port should work fine. I'll test it anyways
  2. Cutting the wire on Pin 19 was necessary because that was the USB ground, which appears to be tied to the car ground somehow.
  3. More wires may need to be cut if there is no cable in order to get into the USB system.
  4. If I can add pins and run some wires, I can access the stereo's CAN (Controller Area Network) Bus and do some cool things. This may be why eServices is disabled.

After doing some research, I found something pretty cool called a CANBUS control module available through a website called K5 Optima Store. It has some instructions on connecting it to the vehicle CANBUS for an optima. The module appears to be available for my vehicle, so the next thing to do in regards to that is to access some schematics for my vehicle. Hopefully I can find some for free, but if not then I could always pay $30 to access the Chilton website for a year. Looks like I may have opened a CANbus of worms by coming across this info.

When I got home, I was able to remove the center console of the car and dug the remaining screw out. It turns out that the USB port just goes directly into the car's wiring leaving me with only a few options.

  1. Replace the USB/AUX unit with one that accommodates a cable off eBay for around $30 and get a cable for around $50
  2. Wire a connector of my own making directly into the car's wiring.
  3. Replace the connectors with cables and bypass the car's wiring which would have the side effect or removing the lighting of the labels on the ports

Due to the fact that I will probably eventually get a new stereo, I decided to go with the cheap option and wire a standard USB plug directly into the car and make an adapter that goes to my stereo and I'm just going to ignore the CANbus stuff. I have a sneaking suspicion that the eServices communicates with the car using the USB port.

I went ahead and cut/soldered the USB port into the car wiring and re-soldered the video camera connections on better using heat-shrink tubing instead of electrical tape. I then went ahead and created the adapter. I hooked everything back up, but the USB still isn't working. It turns out that I incorrectly guessed the colors for the USB Data + and - wires and put them on backwards. I fixed the adapter and I will try it out tomorrow and I need to fix the data wires in the car. For now I just disconnected the USB and will probably try and take care of that at lunch.

Today at lunch, I finished routing the video cable to the front of the car. After work, I headed down to my friend's house and finished connecting the camera to the stereo and it tested successfully. I realized that both the camera and stereo were trying to display guides, so I disabled them on the camera when adjusting the settings. I feel like the camera angle should point up a little more and I spent some time trying to figure out a good angle. I may try and create some kind of wedge so that I can change the angle a little, but it is still completely useable.

The next step I tried to do was enable the eServices on the stereo and from what I can tell, I will need to perform a software update first. In order to update it, I need to get the USB port connected, so the next step will be opening up the area with the USB and Aux port to see if there is a cable connected. Hopefully I can find and retrieve the other screw at the same time. Another thing I need to do is test the aux input to see if that is working.

It's been over 4 years since my last entry. I've moved several times across the country and worked at a few different places and that has consumed a lot of my time, though I have worked on a number of projects. Here's a highlight of some of the interesting things I've worked on since then.

I have put the robotic car project on hold since then to work on some other things. First of all, I built a 3D Printer several months after my last blog entry and updated it with some new components about 2 years later. It was a RepRap Mendel Prusa Iteration 2 with a few upgrades. After the printer had some current back-feed through my USB port and caused me to have to send in my computer for repairs, I've been a little cautious about working on the it. However, I will continue my work on it again soon.

Around the end of 2014, I got into flying RC helicopters and had a lot of fun doing that. I ended up at one point having 2 quad-copters and 3 collective pitch helicopters. I have sold my biggest helicopter since then, but still have the quad-copters and 2 smaller helicopters.

In 2016, I was working on the design for a new invention. I had the idea for it in 2014 and was one of my motivations for building a 3D printer. I built a prototype of the electronics part of it and was in the process of working on the programming for it. However, due to a death in the Family we made some sudden life shifts. We bought a school bus to try and convert into a skoolie, which basically means that it's an RV that we could totally customize. Around the end of the year, I ended up getting happily married. Shortly after, we moved to Florida shortly after for about 6 months. After we got back, we ended up just doing the base work on the bus and selling it for a little less than we bought it for, though we did make use of it for moving stuff and storage, so in the end we pretty much broke even.

While in Florida, I did a complete website redesign with a new Laravel backend. I also decided to get into doing video game design and created another blog for that. I kept up work on the game throughout most of 2017 and decided to place that on indefinite hold. As I was working on it, even though it's a pretty cool project, I decided that I knew there wasn't much of a market for that type of game. I think the main reason I was wanting to complete the game was just to start a portfolio so that I could get into game development. However, after some reconsideration, I have decided to stay with web development because there is a lot more demand/opportunity to make money with it. I am in the process of exploring ideas to pursue that will be more profitable and I can pivot from there. I'm also thinking about renaming this section from Robotics to either Electronics or Electronics and Robotics to accommodate the wider scope that this is ending up encompassing.

In late 2017 I started getting into retro computing and purchased a commodore 64 that I started making add-ons for. I made a video that I was intending to post onto YouTube of taking apart the keyboard and cleaning the entire computer. The computer turned out great, but the video ended up only being half-edited. I still intend to at least finish it.

During this time, we went through several vehicles. We bought a Honda Civic in 2016. At the same time we bought the bus, we also bought a Ford Taurus wagon for a great price through the same auction. We ended up selling the Honda Civic shortly before moving to Florida because it gave us some money to travel with and we didn't need to maintain a second car. We used the Ford Taurus to drive across the country to Florida. In Florida, we ended up inheriting a 2013 Dodge Grand Caravan and sold the Ford Taurus to some friends we made there. We drove the Caravan back across the country and still have it.

Earlier this year, I stumbled across a YouTube video that had a huge impact on my life. It was about some of the things that rich people do vs poor people and I decided to watch it just to see how some of the strategies I had developed in life compared to the list. One of the things that really stood out to me is the number and type of books that rich people read. The number I got was that rich people tend to read 50-60 books per year, which are usually non-fiction. On the site Goodreads, I decided to take up their reading challenge for this year and set a goal of 50 books, which I figured I could do about 1 per week. I decided to read mostly non-fiction book and started looking up some recommended reading lists for financial and business books. I started reading about a week into January and ended up successfully hitting the goal around the end of April.

During the course of those books, I really expanded my financial education and it was one of the best things I ever did. Things just started falling into place between paying off some finances, paying back friends that we borrowed money from, being able to save up money, and business just being good overall. I was able to purchase a second car for myself because it was getting to be a real hassle to share a car when we had different agendas. I ended up buying a 2016 Kia Forte, which brings me to my latest project.

While car shopping, one of the cars that I test drove was a little out of my budget, but had a back-up camera as part of it that I really liked. I really liked the car I ended up with, but it didn't come with a back-up camera, so I did some research on it. I ended up getting an upgraded Kia stereo system off of eBay for about $64 and an aftermarket back-up camera off Amazon for about $15. I went ahead and mounted the camera where it is supposed to go, wired it into one of the reverse lights for power and installed the new stereo. With an inverter and a small LCD TV, I was able to test that it was getting a working video signal through the camera and the reverse position signal is delivering 12v, which I tested with a multimeter. I was finally able to get it to display a signal on the stereo once I cut the wire for the reverse signal (pin 19), which appears to be grounded and attached the wire directly to it. I was able to get the video signal through Pins 6 and 18 and it displayed properly. I still need to run the wiring through the car, I dropped a couple screws for the radio down into the console that I need to retrieve or replace and I need to figure out how to get the USB port to work with the stereo and then all should be good.

Update: I found one of the screws after removing one of the side panels to the console. I have also shortened some wires and fed the camera cable up through the rear driver's side door. I updated this blog somewhat, though there is more to do.

I went ahead and soldered all of the parts on the board. During assembly, I discovered a design flaw that reverse the I2C Pins over the voltage converter. So, SDA 5v translated to SCL 3.3v and SCL 5v translated to SDA 3.3v. Ok, no big deal, I'll just reverse wire any external I2C devices. Then I remembered that my gyro/accelerometer/compass was wired to the I2C 3.3v side, so I cut the traces with an exacto knife and used my circuit writer pen to draw new ones. I'm still doing testing at the moment. The SD Card Reader worked awesome, but I'm running I2C Scanner and it just keeps getting stuck on "scanning...". If I unplug my board from the arduino, it runs fine. I found 2 traces not working while testing and fixed those. I may end up wiring my external logic converter and the compass to a breadboard and see if I get different results. If so, at least I have something to compare it to.

Well I guess I lied. I got so involved making a new board, I didn't take any pictures. Sorry. Well, I went and applied a solder mask as well as a silkscreen. Unfortunately, during the drilling process, I was off center enough to ruin some of the traces. I tried fixing them, but was unsuccessful. So I went and made a third board using information I gleened from making the first 2 boards.

Even though the second board was well aligned, the third one was near perfectly aligned. I was very careful with the drilling and did a much better job and the result turned out great. When I went to tin the board, part of the directions states to submerse the board in ammonia to stop any corrosion. Unfortunately, I discovered that ammonia melts the soldermask. This was helpful for redoing the solder mask since I wouldn't need to scrub the board anymore.

Right after etching the third board, I noticed a broken race while doing electrical testing. I used my CircuitWriter pen to repair it and this was the best I ever had it work. I applied it, blasted it with a heat gun for a few minutes and cut it to the right size with an exacto knife. As I went along, I made notes of the process along with little tips and tricks to get things working consistently well. After a little electrical testing, the board should be ready to start adding parts to. We'll see how it goes.

So here's a quick update. I finished the circuit board and got all of the parts soldered on, but it didn't work correctly. While trying to fix it, I ended up burning some of the solder pads off. So I'm working on making a new one and using what I've learned from the first one, I'm going to make it better. I had taken some pictures while working on the first board, but my memory card went bad, so I lost all of the photos. So I'll try to take more pictures as I make the new board. So far, I've cut it out, scrubbed it, made a cardboard cutout (which required gluing 2 pieces of cardboard together) to help feed it through the laminator and made some alignment holes that I can stick pins through, that will end up acting as pilot holes for the main drill holes in the board. This should not only help me with getting the doube sided board aligned, but also holding the paper in place for me to tape onto the cardboard. Anyways, that's it for the update.

So I went ahead and after about 5 tries, I was able to get a circuit board that looked reasonably good. Things I learned during this time include:

  1. Drill holes and use those for alignment.
  2. Use a cardboard jig to help steady the design.
  3. Keep running the board through until the parchment paper looks like waxed paper (no design stuck to it). It took me 8 times for the good one.
  4. Wipe the board with acetone prior to applying the design.
  5. Give the laminator plenty of time to warm up.

So I transferred the artwork to the board, etched it (wasn't quite as scary as I thought), and tinned the board. Then I drilled holes. I counted 310 holes in the board (including standoff 5 holes). As I was drilling, I noticed that one side of the board was misaligned by about a millimeter. I did as good of a correcting job as I could.

There was only 1 trace that was broken from etching, but I can solder a wire across that. During drilling, I broke another due to the misalignment. I was able to solder a wire across that. Electrical test were all good. I had a minimal amount of scraping/breaking traces that needed to be done.

Then I started soldering. I was able to get the smt devices on with no problems. The through-holes are where it gets rough. Since I am soldering on both sides of each pin because I don't have through-hole plating, nor do I have any vias, the soldering portion is much more difficult. That means I have to solder around 600-650 points of contact. So far soldering has been going well. I was going quickly, but I did a quick bit of testing and realized I had solder gaps. So after hunting them all down and fixing them, I started performing frequent tests as I went along. I'm roughly 60% done at this point with the soldering. I ended up breaking a tiny trace between 2 larger traces. I soldered a wire in between and after I verified that nothing was touching, I took some clear nailpolish and coated the wire, which also glued it in place. I like to start with the difficult to impossible things and work my way to the easier stuff, because once they are addressed, then the easier things are easier to troubleshoot if stuff does go wrong.

Anyways, it's more soldering at this point, so I'll update this when I'm done. Hopefully that will be tomorrow or the next day.

Wow, it's been about 2 weeks since my last update. During that time, I've made so many attempts at making the circuit board with varying degrees of failure. I am so close now. So, here's what I've done.

First I started by cutting the board out. I found out later that you should leave a little margin, but it seems that this would work well for aligning the 2 sides.

I originally started out printing my design onto some cardstock with a shiny side like I've done before. So far everything was going as planned. Then I ironed the pattern on like before, but it wouldn't take. After about 6-7 tries with 2 irons, I gave up with that method.

I did some internet searching and came up with this excellent instructable. I got some parchment paper, hydrochloric acid, a pyrex dish, and a laminator from harbor freight. I picked up a face mask for fumes just in case while I was at it.

So next, I went and tried to print the pattern on the parchment paper. No go. It failed consistently every time. Apparently the HP Laserjet 4100 does not work with this. After trying it a number of time, I broke the fuser, putting the printer completely out of commission.

So I needed a new printer. I looked up the one in the instructable and saw that it was not only very economically price, but on sale for a couple more days! So I went ahead and got that, figuring I could always return it if it didn't work for my needs. I went and tested it and it did it almost perfectly. It kept coming out messed up on the right side. So I made it so the design printed on the left and it now comes out perfect everytime.

Now that I had it printing on the parchment paper, I tried ironing it and laminating it. With the iron, it kept either not adhering to the board or coming out smudged. Usually both. With the laminator it wasn't adhering to it.

I took a break for a few days and then did some internet searching to see if I could find an answer. I came across an article for mounting a dimmer switch on my laminator in order to slow it down. I went out and bought a dimmer switch and started hacking it apart. Even though it says the dremel didn't work well on the aluminum, I had bought some reinforced cutting wheels and those worked excellently. I only wore it down about an eighth of an inch. My dimmer switch was bigger than the one in the article, so I had to do some additional modifications. I had a circuit board inside. One of the things I had to do was narrow it down. I ended up desoldering the 2 components on the board and relocating them. I had to use some wire solder to the components' ends. On one part, I had to create a new hole, so I scraped the solder mask off with an exacto knife and drilled a hole nearby. Using some soldering flux so that it would stick, I solder it onto the scraped off part. I then was able to cut about a quarter inch off the circuit board. I also lost the metal contact that the dimmer moved, so I had to fabricate something out of some spring steel, which turned out very nice. I got it in there and used a couple screws to hold it against the front. Unlike the dimmer in the article, I trimmed it up enough so that I didn't have to cut off a wall or use epoxy, so I can remove if necessary. Overall, it worked nicely on the first try and the know was mounted in the perfect place.

That took me a couple of days, which I just finished yesterday. So, back to the main project. I tried it out today and it sort of worked. I mean the laminator itself worked, but everytime I tried putting it on the board, the board moved when it got sandwiched between the rollers. However, even though it wasn't lined up, the toner did transfer really nicely. The next thing I tried was using some doublesided foam tape to try and hold it in place, but the board moved anyways. My next thing to try is I took the cardboard back of a notepad and cut out a board sized hole. I'm going to try taping the parchment paper directly to it and hope that holds it in place.

I'll try again a little later and see if that works. I still need to make the tinning solution, which I guess takes a while.

Also, I came across a nice instructable on putting a soldermask on that would work well from home. I priced out the materials needed to make this, and it came out to about $80. It would however, yield many boards with the supplies you would get. The result is so much easier and nicer than the spray paint method I used before. I probably wont do it for this circuit board, but maybe for the next project.

Another option that I thought of, which would probably work with items I have on hand is to take the aluminum from a soda pop can and flatten it out with something like the laminator. Then you sand it really well to get the coating off and use the toner transfer method to put a mask on that only exposes where the solder pads are with the rest being the resist. Then you put it in a 50% solution of HCl and Hydrogen Peroxide to etch it. Remember to always add the acid to the peroxide and never the other way around. They will react and as you add them together, you want the peroxide to be in greater quantity than the acid until fully dilluted. So, you etch the holes where the solder pads go until you have holes in the metal. Clean it off really well and then lay it on the circuit board where you are applying the solder mask. Get some vasoline out and wipe it on so that it goes through the holes and sovers the pads on the circuit board. Then take your favorite color of hobby spray paint and spray it on the board. Give it time to fully dry and then you can wipe off the vasoline. I've not actually tried this out though, so I may be totally off or the results may be less than ideal.

I also came across a nice idea for adding a silkscreen to the board. Basically, you use the toner transfer on the completed board to put your words on, throw it in a toaster over, then use a white crayon over it while it's still warm.

So I've been quite busy as you can tell by my longest post ever.

Finally! I have everything I need to make the board, though some green spraypaint would be nice for a solder mask. Anyhow, I have a drill press and I've received all of my parts. I reworked the board design based on the parts and I was able to get them to fit much better. I still want to add a couple of LEDs and resistors for power and status indicators and put together another test circuit, however, I should be able to start, if not finish, making the board this weekend. I also got some breadboard to stick to my protoshield, so now I can make a final test on that board.

Yesterday I received the Gyro/Accelerometer/Compass sensor in the mail (only 1 day later than estimated, but it came from China). I found out today that my order had been cancelled due to some credit card authorization error. I just resubmitted the order today and payed more for the shipping because I didn't want to wait another 2 weeks. I also ordered some more pin strip headers and some mini breadboard for my arduino protoshield.

I stopped by radio shack yesterday and bought some circuit board etchant, a couple soldering iron tips and a better pair of flush cutters. My old one looked like somebody tried cutting paperclips or something with it.

At this point, I need to get a drill press, some tinner, some acetone and wait for my card reader to get here. I still want to finalize my board design. For instance, I want to add a reset button and I may throw a 6-pin ICSP header on there as well.

I'll probably get the first 2 items tomorrow, then it will pretty much be a waiting game, but I'll probably get the reader in the middle of next week.

There's not much to tell. I finished with my circuit board design, although I'll probably be fine tuning the design. I did come across an arduino shield that is similar to what I have been designing. The main differences are that I have multiple plugs for I2C, SPI, and UARTs with all of the necessary signal wires included in each plug. I also have special connectors for the gyro/accelerometer/compass, the SD Card holder and my DIP switches. I have 3.3v and 5v I2C with the voltage logic converter built into the board as well as the pulldown resistors for the DIP switches. Because I think my board will be a much cleaner solution and aI spent all that time, I'm probably going to go ahead and make my board.

I was able to desolder 6 more mosfets from boards, so that should give me plenty for prototyping. I'm getting pretty good at desoldering SMD components. Yesterday, I broke 2 of the 4 that I tried to remove and today, I got all 6 in perfect condition.

So, I went ahead and built a prototype logic level converter to make sure the components I have would work. So I built it on some 20 year old perf board (it really is) and soldered the smd components, some through hole resistors and some wires on the board and tested it. It tested as expected and was able to determine the logic both ways at the correct voltages, so I can incorporate that into my design since I already have the parts.

The design is still coming along. With so many planned connectors, there's a lot to squeeze into a board that won't be any bigger than the arduino mega 2560 (Approx 4 in. x 2.1 in.). Additionally, I have the challenge of using the light version of eagle, which limits your schematic to 1 page, so I need to carefully arrange it on the page so I can fit it all in. Honestly, I'm not sure how well it will work, but I won't know until I try everything I can. I figure the worst case is that I need to have fewer connectors than I originally planned. Anyhow, I'll keep working away at it.

Well, I've been out of commission for a few days because of my back, but I've made some progress. I went through some tutorials for Eagle and now I'm working on my own board. I went ahead and designed standard connector wirings for each type of output. I based it on the standard RC 3 wire plug and went from there.

At this point, I'm running into a slight design issue, which is I2C running both 5v and 3.3v devices. Since the the 1 device I will definitely hook up runs at 3.3v, I'm partial to that, though I want to be able to hook up 5v devices in the future. 1 suggested solution on the internet is to use a logic level converter. According to this arduino page, there are some basic designs for a logic level shifter. I was able to obtain a couple SMD N-channel Mosfets off of some scrap circuit boards I had laying around. I should be able to integrate a logic level shifter on board of the shield.

I've been looking into using SMD parts because I can already tell the board is going to be pretty packed. I'll need to see if I can find some through hole mosfets for prototyping purposes as well. Anyways, I'll continue working on the design and hopefully be able to make a simple prototype for the level converter.

I've been working hard on a test board for the robot. I believe I have all of the sensors that I have received mounted on my bread board and everything fully wired together, except for the DIP switches. I hooked up most things with wire ties for temporary measure and they fit so well, I may just leave it that way or at least do something similar if I have to move them. I didn't attach the arduino or the breadboard, so they're currently just hanging there.

I'm going to continue working on getting all of the required sensors in place, defining standard connectors, and developing a master program while I wait for the parts I have on order to arrive. By having standard connectors for digital, analog, UART Serial, SPI, and I2C connections, I'll be able to plan for expansion and know I won't need to make a new board in the future. I also realized I'll have to get a mini drill press. I don't have access to one anymore and that's necessary to drill holes for a homemade circuit board.

I also am starting on a circuit board design. I downloaded Cadsoft Eagle and installed it as a free version since the limitations, at this point in time, shouldn't affect my design.

So, I've been working on getting the sensors working on the arduino. I decided to start with my existing Accelerometer/Gyroscope chip (MPU-6050), since it is the predecessor to the MPU-9150 that I ordered a few days ago. I was able to get accurate readings off and even so far as to use the build in digital motion processor using sample code in the i2cdevlib library that can be downloaded here. As a bonus, this sensor also can sense temperature, which I'm pretty sure the one I ordered can do as well. Although I hooked up my magnetometer through its auxillary I2C connectors, I have yet to test it.

Next I hooked up my IR detection sensors, but I haven't tested those yet either. I created a simple circuit with a CdS cell (photocell) and a pulldown resistor and hooked that up to an analog port and that tested successful.

After that, I hooked up my IRDirection sensor. I found some code on the internet that wasn't quite working. After changing a couple things in the code, I got it working successfully. My idea was to use the photocell to detect the light level and if the conditions were right, it could make use of the IRDirection sensor to go towards light. The sensor is really more of a light detector that senses the IR in light and can tell which direction it is strongest.

Next, I need to test out the IR obstacle sensors, which should be really easy because they are just a digital on/off. Then I can work on getting the data for the compass and showing that. At that point, I believe I will have tested all of the sensors I have, including the ping sensor and RC Inputs from before. I should work on the outputs at that point. I obviously have the robot's servos and I wanted to use some LEDs as lights on the robot, since it is a vehicle and then the fun part is to try and combine the sensors to overcome various obstacles.

With planning for some future expansions,such as maybe a color sensor, GPS, possibly a camera, and additional servos or additional input sensors, I should be able to start working on a board design.

Happy New Year!

I assembled the arduino shield kit yesterday. Then I started taking inventory of all the sensors I have and all the ones I plan on getting. I ordered the SD Card board with the built in converter. I also purchased a MPU-9150 based Accelerometer/Gyroscope/Compass chip. I decided on this chip rather than a separate magnetometer and Accelerometer/gyroscope for a couple of reasons. First, it takes up less room on the board. Less room means more compact electronics. Second, for compass readings, it can automatically take tilt into account to get accurate compass readings.

At this point, I'm figuring out all of the connection needs for inputs and outputs. Next I'll prototype a circuit out with some breadboard and then I can start working on an actual circuit board design.

It's been a while. As a quick update, I ordered and received those additional parts, started a new job, and have moved across the country. Somebody at my work had done a presentation on RC stuff and I learned about some new stuff that was out there. It has been a few years since I originally looked up my information on Radio Control technology, so I did some more research and discovered something very important and a bit frustrating (in a good way). I found this article on Sparkfun that describes how to hook my RC receiver directly to my arduino and have access to all of the channels without taking up any more processing power than I was already using. So I unpacked my robot last night, took it apart and as a test tried hooking up my receiver to my arduino and seeing if it read the values. The test was successful.

What does this mean? It basically means I can take the PIC board out of the equation. It does mean I will need to use about 8 more pins on the arduino, but since I upgraded my arduino to an ATmega, this isn't really an issue. I will need to update my code, but it should make the code much simpler. At this point, I need to work on the shield redesign that will take these design changes into account. Before I do that, I will assemble the shield kit I bought (I may end up using this as my final board anyways) and start hooking up stuff to here. I need to work on finding my design notes regarding which pins I was planning on hooking the additional sensors to. If I can't find my notes, I may need to do some more research again.

My parts arrived yesterday. I started cutting out some SIP connectors to connect the accelerometer, digital compass and directional IR sensor. The other IR sensors came with cables, so that was nice. Unfortunately, I ran a little short on connectors, but I was able to salvage a 4-pin connector from a computer speaker. I also found some ribbon cable that I'll use for these connectors. This means I need to add some pin headers for a 4-pin, 5-pin and 8-pin connector to the robot. That means I will probably have to remake my shield, which I thought I'd have to do anyhow so I can make use of additional pins on the bigger arduino. For testing purposes though, I will hook stuff up to a breadboard and connect that to the arduino using single wires. Once I get everything working, I'll redesign a shield. I'm sure I'll need to get more SIP connectors and pin headers to get that finished though. When you try desoldering used pin headers, it gets ugly. So, I'll be adding that to my shopping list. More work to do on it.

According to package tracking, the sensors were just shipped yesterday. I'm still waiting for them to arrive. They're shipping overseas, so it may be another week or so.

I haven't had any updates for a couple of weeks because I haven't done anything more yet. I ended up ordering some sensors for my robot. I ordered 4 IR sensors, a directional IR sensor module, a 3-axis accelerometer and a (digital compass). I just got notice that those shipped out today, so hopefully they will be here in the next week or so. I'll continue to post when there are any updates.

For the most part, my program is fully operational now. I say for the most part because I still have a memory issue (probably a leak) that I need to hunt down. Looking at the stack trace, I suspect I may have overloaded the Debug Log TextView control. However, I now have it looping in a thread and updating the UI. I had to do a little function rewiting to make it so the communication didn't need to work as hard. I still have a few stability issues to fix. For instance, if the Android falls asleep while still connected, it needs to be rebooted. The program also seems to have trouble realizing it isn't connected anymore if you reset the Arduino without disconnecting first.

I want to optimize the code so that it's not so memory intensive, even if the issue is with the textview. I'll probably make it so that only certain types of messages get printed to the TextView and the rest go to the system log.

I now have the code that shows the channels times. This is mostly working. Occasionally, a channel time is never requested, so I'm working that out. Anyway, I made quite a few changes to the overall program based on certain problems.

First of all, I was running into the problem of the program occasionally crashing as I worked on new features and as a result, I couldn't look at my log tab. So, I created a function that records it to the system log and outputs it to the log tab at the same time. After that, I was able to see a lot more of what was going on.

When I received data back from the arduino, I was using brackets to delimit the commands and I would receive the data in chunks and I would keep adding it to a buffer and process if it started and began with brackets. That worked fine for sending one command at a time, but when I started receiving multiple responses, I would get it chunked together with 2 or 3 responses sometimes. I added some code to check if the responses were chunked and would call the function to handle the responses and remove pending commands, which effectively turned it into a queue.

I noticed that when I rotated the android, it was losing all of the UI data. This seemed to only happen when going from portrait to landscape and vice versa. I decided to only allow portrait mode (and reverse portrait). I liked the layout for portrait much better than the landscape one I came up with, so I removed all of the landscape stuff. I have a little debugging to do and I need to add the ping sensor data as well as loop the program to get constant updates and this phase should be done.

I did have a good idea yesterday to add a section that I can use to reconfigure the way I want the robot to respond or behave as well as enabling and disabling features dynamically. This would be excellent for robotics competitions with certain rules and would take advantage of using a tablet, since it's so portable.

I added the code that shows the features enabled and shows the lights for active RC channels. After a number of program crashes, I narrowed down the rogue code and had it check for bad values and display error messages to the log about why it was encountering those values. After that it started working. I optimized the code a bit by replacing parts with more efficient code as I figured out some better ways to do things. After getting that working, I tried making some channels inactive and a bug in the PIC program was immediately apparent. This is exactly why I'm developing my Android interface! It's a minor bug, but one I'll address as soon as I finish this stage of the android program.

Next I need to get the RC Channel Values for each of the active channels, set the value labels, and set the progress bars to show a visual of where the channels seems to fall. After that, I need it to display what the Ping Sensor is detecting. I also need to set the program to not read the RC Channels if that feature is set as disabled and the same for the Ping sensor. Then I need to clean up a few graphic details and it should be ready to run for now.

I also found a couple of interesting IR detection sensors. There's a basic one that I'm really looking getting about 4 of, since it looks like it does exactly what I want in an IR sensor for a great price. The more Complex IR Sensor looks interesting as well. It communicates with the Arduino (via Serial I think) and it can be used to tell where an object of interest is located. This one might be interesting to use with a camera that automatically point towards where it senses an object. So, that's where I am for tonight.

It's been a little over a week since my last update, but I've been working on on my robot. I actually made a lot of progress just tonight. Over the past week and a half I've completed several important items including coming up with a basic layout, which turned out pretty much what I sketched out on paper. The code for returning requested data is now complete on the Arduino side. I'm working on getting the Android interface to update based on the returned values.

I currently have the switches changing to the correct values, with which the command is issues upon connection establishment. I created tabs as I had planned and and finished laying out the interface tonight. I also created a landscape layout to accomodate turning the Android. I used Layout includes and created each section in separate files so I could easily rearrange things. I created a useful log tab which I can use to put any detailed debugging info on. The servos tab is for future use which I plan to use to control the servos with (if it's useful).

The next items are to finish are to get the rest of the data to display on the interface and then start a loop to get the android to send commands to request each piece of data so that the interface is constantly updating. At that point it will make sensor development much easier. For instance, I could create an IR sensor tab and display whatever test data I would like. This would allow me to get much more data than I could with a handful of LEDs or even an LCD display. I still need to mount the new arduino board (which is the board I've been using for development) onto the robot as well. It's currently sitting on top of the other board with a piece of paper acting as an insulator.

I ended up attaching an external LED, which worked great. After doing lots of reading and internet searching, I've finally come up with a solution that has everything working nicely. I found a very nice Android Library called usb-serial-for-android. This was written with the main purpose of communicating with the android. Additionally, this library includes drivers for communicating with many Arduino devices including FTDI based arduinos like my Diecimila, which will save me a lot of time. Although the documentation is sparse, I was able take the example program and intergrate it into my own program. I did need to write a custom decoding function based on the HexDump.dumpHexString() function source code.

I also needed to update the Arduino test program slightly as well as my method of connecting. The current procedure is to plug the arduino into the program while it is running, give it permission to access the USB device, then push the reset button on the arduino. When that's done, a "connected" command is returned to the android, which then starts sending commands to gather information.

Additionally, I was having trouble with my program locking up the android whenever it went to sleep. As soon as I started unregistering my Broadcast Reciever in onPause() and reregistering it in onResume(), that seemed to solve the problem.

These were some tough obstacles to overcome, but with basic communications functioning, it's time to start integrating this into the main program and gathering relevant information, which I'll start on soon.

Today I figured out how to update a text field from a thread by using the TextView's .post() method. I ended up creating a function that I can just call with the string and it tells the UI to update the text field. Anyhow, after I did that, I found a few errors in my code and fixed those. I looked into the USB specification documentation to figure out exactly what exactly the commands I found online to send to the arduino did. After some analysis, I found that it sets the Serial Line to 9600,1n8. However, my arduino was trying to talk at 57600, so I figured out the correct bytes to send it to request that speed. Now when I plug the arduino in, it tells me how many bytes were transmitted via bulkTransfer and the receive light on the arduino flashes.

I'm trying to turn on the built-in LED on the board, but for some reason it won't turn on when connected to the Android, even if all I have is code that tells it to turn on, so I need another way to test that data is being received. Most likely the arduino is correctly receiving the data at this point, but I don't like running blind with it when I'm doing things I've never done before. I'll probably try using other pins on the arduino and hooking up an external LED to see if that resolves the issue. Once I get the sending and receiving working on the Arduino Mega, I'll try getting it working on my diecimila. I'd like this project to work on all arduinos and I'm trying to write the code in such a way in case I decide to go with a different arduino in the future.

I haven't had much opportunity to work on this over the weekend, although I did end up replacing the touchscreen glass that fits over the LCD on an android tablet that had cracked and that was very successful. I finally did some work on it today. I'm starting on working on the communications between the Arduino and the android. I set up the code to set up the serial connection and perform a bulk transfer. It's not quite working yet, but when I was trying to debug it by having the program print the status to a text field, it kept crashing until I remembered that you aren't supposed to access the UI from a separate thread. So the next step will be coming up with a way to have the UI automatically put the value of a variable in to the text field so I can indirectly write to it that way.

So, for the past couple of days, I've been focusing on the Android code. There's a lot of learning to do, but as I gain a better understanding, I also understand new concepts that previously looked foreign to me.

Yesterday, I took some USB examples I found and figured how to integrate them into my code. It's not working yet (I had to comment out a bunch of the code), but it's closer. I ended up adding some code to request permission to use the device and that went ok.

Today, I ended up figuring out about interfaces and endpoints. You have devices, interfaces and endpoints that are in a tree hierarchy. By specifying Vendor ID and Product ID, you narrow down the specific device. From there, the device may have 1 or more interfaces. Each interface is like talking to a section of the board. For the Arduino Mega, I believe Interface 0 is to talk to the USB transfer chip and Interface 1 is to talk to the microcontroller itself, which is what I want.

From there, each interface has 1 or more endpoints. I've only seen 1-2, so I'm not sure if there are more. For my interfaces that have 2 endpoints, 1 is an input interface and the other is an output. I think you use these interfaces for sending and receiving data between the devices. Because the interfaces and endpoints are quite different in layout between the devices, I wrote some code that queries the arduino to get the information. I need to further write it to traverse the interfaces and endpoints and search for two endpoints that have a type of USB_ENDPOINT_XFER_BULK with one being USB_DIR_IN and the other being USB_DIR_OUT. That's about as far as I've researched. I still need to figure out how to actually use the endpoints to communicate with the Arduino, but I have some material to read to help me figure that out.

I went ahead and put the new code on the old board, but it worked fine, so I knew it had to be something to do with the differences of the boards. I started a new Arduino project file and kept slowly adding things in with it working fine until I got to the SPI stuff. Looking closer at the Arduino documentation revealed that the boards did not use the same pins. However, the 6 pin ICSP headers had the SPI pins on them and were consistent between boards. I went ahead and made some modifications to my shield and wire harness so that it was able to plug into the ICSP header rather than be wired to the board. I went ahead and tested it and the SPI code was working again. Unfortunately, there are now additional things to plug in between the 2 arduino boards, so I will most likely redesign my shield eventually and have it plug directly into the ICSP header in the new design. I'll also be able to take advantage of all of the extra pins that way, but before I get that far, I'll build some more sensors. First though, I'm going to get the tablet working with the robot and go from there. At least this is forcing me to review all of my old code, which is very helpful.

It's been a while, but I've been getting back into the robotics project again. There are a couple new things. First of all, I kind of broke the ICD2 board by plugging it into an incorrectly wired USB port. When trying to replace the USB chip, I lost some traces, so I may have to remake a board in order to get that reworking, but that's on hold for now.

The current project is connecting my Android tablet to the Arduino and using that for testing/debugging purposes. To do that, I'm learning Android programming. So far I've made a program that runs in host mode on the tablet and detects when the Arduino is plugged in and unplugged. Then I started working on the Arduino end. I'm starting work on code that communicates with the computer in serial mode over USB. That's coming along pretty good so far. I picked up an Arduino Mega 2560 R3 in order to upgrade the board for my robot to one with more connections for future expansion. I integrated the serial code into the main OS and programmed it onto the new board. By looking through the source code, I figured out where to correctly plug the wires. However, when I plugged in the new board, it didn't quite function correctly. I plugged my Arduino shield into the old board and it functioned correctly, so it's either the code or the new board. So I'll try reprogramming the old board and see what happens. After I get the Android tablet working with it, that should make testing this much easier.

Well, I did get some more work done on the servo replacement board. However, due to too many components being required, I won't be able to make a board that fits in the miniature servo. However, I do have the option of taking the original board out of the robot and putting it back into the original servo and then putting the board I'm designing into the robot. I'm almost done with the servo board, but have been side-tracked lately with working on putting MacOS on my laptop.

Some good news however. I ordered an upgraded ATMEGA328 chip for the arduino and received it today, so now it has twice as much memory as before and I have an ATMEGA168 chip to use on some other project. I also ordered some replacement drill bits, so I should be able to make circuit boards once again (as soon as I pick them up). So, despite the 2 weeks of no updates, I have been making progress. Also, I should be able to take pictures with an old camera phone (I used it for some of the first robot pics). I can then take the SIM card out of the phone and grab any pictures off it, so hopefully pictures will be soon to come again.

The last couple days I've been working on the servo replacement board. I've been using the new ICD for programming the chip and it's been working well. Unfortunately, with the PIC12F683 chip, using the ICD2 for debugging purposes requires a debug header, which is a small board that interfaces between the chip and the ICD. In order to get the PIC so small, they had to remove some functionality such as the debug circuitry and the header basically functions as the debug circuitry they removed from the chip. Additionally, with so few pins hooking up an LCD display is impractical, although I found circuit that turns a standard HD44780 LCD in to a serial LCD. However, it turns out I didn't need it since I was able to get each aspect of the chip working and tested through a bicolor LED. I was able to reuse the code I created for reading PPM signals in the chip, but due to the chip running at 8MHz rather than 32MHz, I had to set the timer prescaler to a quarter of the value to get the same numbers. At this point, I need to build a simple h-bridge (just enough to turn the motor a little), test out the functionality of the h-bridge, and assemble the pieces of code I have working and then it should be ready to go onto a circuit board. I've located the SMD components along with their datasheets that I need for an H-bridge (that's the only way I'll fit it into a micro servo), and board design will probably happen in parallel to finishing the test circuit.

Well, I went ahead and swapped the 2 USB chips and to my surprise, both tested good. I now have a working and tested USB powered ICD2 clone on a circuit board. I figure the USB chip wasn't working because of a bad solder job and probably 2 important connections had a short in them. However, my recent SMT soldering skills have become considerably better and the new solder job looks and works excellent. I also went ahead and modified the board so it is using the MC1458 chip. Additionally, I disconnected the Vpp (Programming voltage) from one of the op-amp inputs and that helped increase the programming voltage another volt, so it's now around 11.1 volts which is enough. I think the minimum was around 10.2 volts and I didn't want to be so close to the lower limit. Unfortunately I probably won't be taking anymore pictures for a while. I had a little accident and spilled a drink on the camera, but I still do have plenty of unposted pictures. On the positive side, this new tool should make any PIC development much easier and faster.

I finally got the ICD working yesterday. I ended up attempting to see what the test pin was on the FT232BL and in the process of moving around parts, it suddenly started working. I'm not quite sure of what was wrong, but it was probably a part that had a short in it and wasn't making a connection even though it was plugged in correctly. Anyhow, after I did that it was recognized correctly as a device on the computer. I went ahead and downloaded the firmware into the device, but it wasn't passing the self tests. After careful examination, I found a resistor plugged into the wrong spot and fixed that and it passed the self test after that. I also had a problem with it telling me it wasn't detecting the correct device. I just needed to select the correct part in MPLAB and that was fixed. When attempting to program the connected chip, it wasn't being successful in programming that chip, so I decided the voltage for the MCLR pin was a little too low and replaced my LM324 (quad op amp) with a MC1458 (dual op amp) and it had gone up another volt. Apparently that was enough because it was successful after that. So now that I have a working model of an ICD, I'm attempting to get the board I made working. I'm double-checking all USB chip connections and everything is coming up good so far, but I'm starting to suspect the chip may be bad. So if I can't find anything after a thorough test, the next step will be to swap the chips and use the good chip on the circuit board and test the bad chip out in the working circuit. So that's my plans with that for today.

I've been taking a break from working on my robot and have been trying to get my ICD2 clone working. Back on 2008-6-3 I built a version that wouldn't even show as a device on the computer. After a little troubleshooting, I found a couple board design errors and fixed them so that I was generating 2 voltage levels now. However it still wasn't being detected, so I went ahead and built a version on breadboard. For the SMT chip, I went ahead and designed and built a breakout board, which seems to have come out good this time and I soldered a couple leads onto an SMT crystal. I ended up only using 2 components out of the original circuit and both of them were just socketed chips, so I was able to just pop them out of their sockets. Anyways, at this point it actually is coming up as a device on the computer, however it comes up as USB device not recognized. I've triple-checked the connections to the FTDI FT232BL chip and those all come up as good. Fortunately, the rest of the circuit is breadboarded, so changing connections here and there is quite easy and doesn't require a soldering iron. If I can get this tool working, it will help me a lot with any PIC development. If I am still unable to get the USB portion of this circuit working, I still have the option of using a MAX232 chip. I would just prefer USB since my laptop doesn't have any serial ports (my desktop computer does though).

I finally went ahead and mounted the board with the USB port and DIP switches on it to the underside of the car beneath the battery flap to protect it. This took me a while since I had to carve exact holes for the parts and narrow the board and coverplate to get it to all fit. I also went ahead and shortened the yellow cable that goes between the bottom of the car and the board on top by clipping each wire, slipping some heatshrink tubing on, soldering the wires together and shrinking the tubing over the soldering job. Overall, I think the result looks pretty good.

I've been quite busy the past couple days. I finished making the wiring harnesses, I ended up making another board that sits on top of the arduino, I had to do a little reshaping of the inside of the car, I mounted the Ping sensor, and I updated the code. The board that sits on the arduino is quite nice, since it organizes connections and distributes power very nicely. I can plug my servos and sensors directly into it that way. I also added a connector for an MMC card for the future with enough pins for SPI communication and one of the pins to notify the arduino if a card was inserted. That left 8 digital I/O pins (3 of them are currently being used by the servos and sensor) and 6 analog pins.

After I finished making the wiring harnesses, I realized that the top of the inside compartment wasn't fitting on so easily because I had used slightly heavier gauge wire than the servos had, so I ended up having to do a little reshaping to the plastic inside the compartment including removing the velco off the receiver in order to allow enough room. I also ended up widening the hole that the wires come out of and after that it ended up fitting well enough.

I didn't want the Ping sensor just sitting on the front, so I made a bracket out of a computer case blank and a couple of spacers out of some wall anchors which took me about 20 minutes and screwed it onto the front of the car. I ended up mounting it vertically, not only because it worked better that way, but the other way looked a lot like eyes which was kind of creepy.

With the new board I needed to switch one of the servos to a different pin, so I went ahead and changed the pin number in the code and uploaded it to the board and afterwards the ESC stopped responding to the remote. I guess I must have experimented with the code after the previous upload, so I went ahead and fixed the problem and actually got the code working exactly how I wanted it to. Also, The Arduino team had updated their software to version 0020 (I had 0018), which I downloaded and installed last night. However they had updated the SPI library, so I ended up making a number of code changes this morning to reflect the new library and tested it successfully.

I was looking up information about the accelerometer I had (the LIS3L06AL, which is now considered obsolete) to see what kind of interface it had. It looks like I had decided to go with analog outputs, so I should just be able to hook that up to the analog inputs and be good to go. All I have left to do really is mount the USB board on the underside, route the wiring harness, and drill a couple holes and everything should be done short of adding more sensors and updating the code, which is more of a longterm learning project anyhow.

And finally, I realized I still haven't named this robot yet, so I'm thinking about that. This is kind of a general purpose robotics platform that is fairly easy to change, test, and update for whichever task I want to accomplish, so I will probably be taking that into account when I figure out a name.

I went ahead and mounted both the Arduino and the new board I made onto the robot and created several wiring harnesses. I have 2 hooked up that go from the receiver to the PIC board and have another one going from the PIC board to the arduino for communication. After doing all that work, I finally tested it and it worked great on the first try. Today's work will be finishing up the rest of the wires going from the receiver to the PIC board and doing some work on mounting the USB/Switch board. This will include shortening a really long cable (the yellow one in the pictures) that I'm using which I pulled out of a computer monitor.

I've also been working on designing the connector board that will mount on top of the Arduino. It has a place for the SPI wiring harness to be soldered on and a place for an MMC card for the future to go. In the current design, I have 3 pin connectors with (Ground, V+, Signal) next to all remaining digital and analog inputs and outputs. I also added headers next to the remaining unused pins in case I decide to make use of those in some design. The purpose of the board will be to give a place for all existing and future connections to plug in neatly while still allowing for expansion of the robot. I'm going to wait a little before making this board in case I have any last minute design change ideas.

While I was going through my parts a couple days ago, I found 2 more IR TSOP1738s which would allow me to probably build a total of 4 IR sensors of standard design with what I have on hand. I also found an additional IR LED that I had bought. After I'm done with wiring and mounting completed items, my plan is to go back to the IR sensor and finish up the design with which I'll make 4 circuit boards for the IR sensors.

I've been working on modifications to my desk the last few days, but I decided to do some more work on the robot yesterday. I ended up making 3 boards complete with parts. I haven't tested the boards yet, which is on today's agenda. One board is the DIP switch and USB port board, which will be mounted on the underside of the car. Then there's the main PIC board, which will read the signals from the receiver and transmit the information to the arduino via SPI. The last board is for another robotics project I'm starting on the side.

I decided to remake the insides of the servo I took apart for this robot and got some PIC12F683 chips as SMT (so I could fit it in the servo). I'm trying to make a simple circuit that will read the PWM codes (that part should be easy) and adjust the motor with an H-Bridge circuit and read the position with the built-in 5k potentiometer using one of the chip's A/D converters. One reason I chose this chip (besides the small footprint) is that it can use an internal oscillator like the PIC18F2620 I'm using on the main board, so that's less components. I'm planning on doing the entire thing with SMT components and most likely a 2-sided circuit board so it takes up as little room as possible. I came up with a great way to do vias on 2 sided home made boards as a hobbiest, which is to basically take a wire and solder it on both sides of the board and trim it as flat as possible. The same thing can be done with soldering component leads on both sides for throughhole parts. Anyhow, the third board is just to allow me to use the SMT component on a breadboard for a circuit. I'm still unsure at this point how I'm going to program the chip, since putting in an ICSP header would make the circuit much larger, unless I can find a small 5-6 pin connector for that purpose. I still have a bunch of modifications to do to the car such as mounting the circuit boards, shortening the wiring harness between the boards and stuff like that.

I continued working with the IR sensors. Apparently what I thought was working before was just noise in the line triggering the LEDs to light up. I wasn't sure what wasn't working, so I ended up building several 38kHz oscillators until I realized the problems was actually the IR receiver module. I was testing with a TSOP1838, which would detect a remote control fine because the signal from the remote is sent in pulses and that is the only way the TSOP1838 works. I plugged in a TSOP1738, which will detect a continuous stream just fine and as soon as I did that the sensor started working. I have 2 of each type of sensor, so with what I've figured out, I can only build 2 sensors at the most. One thing I'm also considering doing is some of my PIC16f84a chips and turning some plain old IR phototransistors (or are they photodiodes?) into something that will detect a 38kHz signal (similar to how I read the PWM) and set a pin as high (or low) to work like a TSOP1738. Additionally, I can also have it emit a signal on an IR LED and turn the entire thing into an IR sensor. The main downside is that each PIC16F84a requires a crystal, but I have enough crystals and chips to make 4 of those. It might also be possible to oscillate the oscillator for the TSOP1838 to work, but the effect would probably be a square wave on the receiving side, which I don't want.

I've been working on some designs for an infrared sensor. I started by searching for designs already on the internet and have been working on getting something that works with parts I have on hand, and then I'll keep working the design down to use very few parts and as much as what I have on hand even if it means using just transistors and resistors if I have to. The idea will be to design a reusable IR sensor module with a small footprint, so I can mount them where I need them and use them in future robots if I want to. I currently have a basic circuit working, but the next step will be to reduce the number of expensive parts.

I went ahead and designed the main PIC board. It ended up considerably smaller than the arduino, which I wasn't expecting. I had measured the holes on the arduino in order to help with stacking, but due to the size difference, I was able to only use 2 holes. I put a placement for a third one so I could mount the boards side-by-side if I wanted. I added placement for 2 extra channel connections if I wanted to include this in the future without having to remake the board. I decided to not include the MMC card on the board since it would have dramatically increased the size. Since I'm not using it at the moment (due to not having the extra memory on the arduino yet to handle the code), I will create a separate board later. I'll probably just end up tying that into a connector board that will fit on top of the arduino. However, I still want to experiment with sensors before making a final design on the connector board.

For sensors, I'm thinking of using the Ping, IR sensors, an accelerometer, maybe a noise sensor, temperature sensor, light/dark sensor, and any other ones I want to try. My plan is to make a standard connector for sensors (probably 3 pin for +5v, Ground, and Signal) and have places for digital and analog signals on the connector board (which is why it would be called a connector board, though I may end up calling it a sensor board depending on what I come up with.

It works!!! After almost 3 years, I now have a working robotics platform. The first test I did was I just used the remote control as normal and it worked great on the first test, which was a great thrill. I set it to ignore the remote if the first DIP switch is on, so it can be used as just a robot without remote input. After that, I hooked up my Ping sensor and wrote a program for it to back up. I had to modify the code a little, but now it backs up if it senses an object within a half meter and stops when there is nothing else in front. The plan is to continue building and testing additional sensors and continue to evolve the main program for the robot with the additional sensors. Of course, I will continue finishing up with the circuit boards for the parts I've already built.

In case you didn't notice, I found the camera. I took some photos this morning and spent some time updating my website so that I can add easy thumbnails (I don't have to have separate images, they are resized with code). I'm trying to add photos next to previous information that talked about a particular subject, like the sketch of the prototype I did and putting the parts on the small breadboard.

Well, I ended up solving the problem with the DIP switches not being read. Apparently for PORT A (and some of PORT B), you have to set the pins to digital through the ADCON registers. After that, it worked pretty good. I still need to get the servo code working, but there's lots of examples so that should be easy. Then I'll test it with remote control input, and then I'll try using the Ping ultrasonic sensor (there's code for that too) and write a small program for the car to back away if something is in front of it.

I was trying to figure out what would work best to mount the boards. I had some old gray plastic spaces, but only had 3 of those. I decided to take some posts out of an old RadioShack project box that I used for some kind of speaker thing when I was like 10. The next step with the posts will be to drill completely through with a 9/64" drill bit (to accomodate a 1/8" bolt) and then slice the tube into little spacers I can use. Another option would be to not drill it, leave the posts somewhere between 1/2" and 3/4" long and feed a screw in each end.

When it comes to making things, I tend to have a few rules I like to go by that really make things go smoothly:

  1. Start by making something that works and improve it after that.
  2. Wait until as long as possible before doing anything that would be difficult to undo.
  3. Make use of materials that you already have. Anything is up for grabs and sometimes a trash can will be a treasure trove of raw materials (just be sure to clean them first).
  4. The internet is full of ideas. If you don't know the answer, it's very likely somebody else will (and has probably asked it with a nice answer sitting next to it.)
  5. If you don't have the right tool for the job, you can often make it.

I wanted to upload some pictures of the progress so far, but when I searched for the camera I couldn't find it. Anyways, I went ahead and put the 18F2620 onto one of my small breadboards and added all the resistors necessary to run it. I also took the code and stripped it down to it's minimal function by removing LCD and LED test code, which brought it to around 750 bytes, which is quite small nowadays. I went ahead and tried it, but wasn't able to get any results with regards to SPI. I decided to separate my code and set it up for the 2 different chips, so I could take what was working and what I wanted and get it to a middle point. It turns out that on my small board I had accidentally tied MCLR to ground, which caused a constantly resetting chip. After swapping that around it started working fine.

Additionally, I kept having problems with my programmer. I noticed it worked fine on the 40-pin chips, but not 28-pin chips, so I figured it had something to do with the 40 to 28 pin adapter (which it did). I eventually narrowed it down to an intermittant short on the PDC pin (pin 27 on the 18f2620). I went ahead and resoldered it and it seems to be working much better.

I'm currently only having trouble with reading the DIP switch values via SPI. It should be fairly straight forward, but it might be something to do with reading a PORT value within an interrupt service routine. I'll start by trying to see if it's even reading the PORT value at all. If it is, I may have to do a little workaround by just reading the value within the main loop and storing it in a variable.

Adding commands into the PIC is actually pretty nice, because if I need to make any parameter changes in the future, all I would need to do is change it on the arduino. I also want to add some code to check if the values are within a certain range like 600-2400 before storing them into the array. By having a command for changing that range, all I would need to do is set it through the arduino.

So far, the project is coming along pretty nicely. I still need to come up with the PWM code on the arduino, which should be pretty easy. After that, I can mount the arduino and breadboard on the car and it can get it's first test. I have an ultrasonic sensor from Parallax that I will probably use as one of my first sensor tests. I still need to at least get the switch code and PWM code going and then I can do the first trial run. Hopefully I can find the camera by then so I can take some pictures.

I went ahead and drew out a sketch of what I wanted to put onto the first prototype board. In this version, I will only be making 2 boards. One, which I already designed, will hold the USB port that will be extended from the Arduino for easy access and a set of 4 DIP switches. The second board will hold the PIC chip, pins for input from the receiver, and the MMC card. Originally, I was debating on whether to use the 28-pin PIC18F2620 or the 40-pin PIC18F4620, which would give me an additional 8-pin port, but upon seeing how little space I had to work with, I decided to go with the 18F2620, which is significantly smaller. At this point, I'm still making preparations for getting the first prototype up and running. At the very least, I should be able to put together a PIC board on breadboard and mount the arduino to get a pre-prototype in the next couple of days.

I ended up looking at I2C another time, but didn't have any better luck. It just seems to be a protocol that the 2 types of chips aren't able to communicate with. I have been going over the possibility of using the ATmega chip I'll be replacing from the arduino and transferring my algorithms for reading timing over to it, so it would be able to communicate better with the arduino, but it probably won't happen.

I ended up making a change to the prescaler of the timer on the PIC chip. I changed it from 1:1 to 1:8 because after that change, when I converter the values to decimal, I ended up with numbers in the range of 1000-2000. Since that was exactly what I was looking for, I'm going to stick with that.

I ended up hooking up all 6 channels to the receiver and as I was testing, I noticed hitting the trainer switch (all lines went high) caused it to get stuck sometimes and not other times. I also noticed it worked similarly when I wire was pulled. I couldn't get anything to work that either stops this or exploits it yet, but I'll keep trying.

While I was looking through a bin of cables, I came across some 1-sided copper board, so that should save me some money and make this project go a bit smoother. I have a robot book I bought a couple years ago that I don't remember mentioning before called Intermediate Robot Building that I've been going through. It has information on building a number of sensors that should really help with my project. Additionally, it comes with a fairly complete design for another robot that would be fun to try and follow along in building. But anyhow, that should be a helpful read as I go through it.

I pretty much worked on learning about the hardware for Arduinos and various AVR chips yesterday. I built a parallel port adapter, known as a dapa (Direct AVR Parallel Access) type that connects to the arduino. I had a little trouble at first since I didn't realize the USB cable needed to be plugged in too at first, in order to provide power. After that, it worked fine. Another option for programming the ATmega chips is to use the arduino itself to transfer the code from the computer to a chip sitting on a breadboard. I'm not certain if the Arduino software sets fuses and unlock bits (required for programming the bootloader), but I do have the commands to do it through the AVRdude software in case, so I should be able to upgrade to the ATmega328 when it comes, which I'm excited for.

I finished getting the autodetect function running, so now the chip has the basic program on it that I set out to do a few years ago. For auto detecting, I just looped through 32 times while waiting for the timer to count from 0 to 0xb000 and looked for activity on any pin. If it saw some, it was set as active by just running activeChannels |= PORTD each time. I also took my timing code and made it a little cleaner and more efficient. The entire program is around 1.5KB, though I have 16KB of total space I can use on the chip.I have been kicking around the idea of using the same chip to send out PWM as well. A simple copy of PORTD to PORTB would probably suffice for normal operation. If I come up with code for sending out pulses (which should be pretty easy), I can do things like have a mode for just holding steering controls in whatever position I left them in. As far as I know, this is one of very few chips that can read 6 RC channels (possibly more) simultaneously, which is why I developed it. Perhaps, after some more work and additional refinement, it could be something to sell, since it's currently very specific to my setup.

I'm also thinking of looking into I2C. I learned a lot working with SPI. In order to get that working, I had to program the arduino and PIC with 2 mismatched configurations and now realize the same thing probably applies to I2C. My main disappointment with SPI is the fact that it takes up not just PORTC, but also uses a pin off the middle of PORTA, rendering it quite useless for many things.

I was looking into expanding the memory for my arduino as well. It appears just popping out the ATmega168 chip, popping in an ATmega328 chip, and programming a bootloader will double it's memory minus the size of the bootloader (about 2K). I'm looking into throwing together a simple AVR programmer as well, which will be required for uploading the bootloader. I placed a sample order for a couple of ATmega328's yesterday, so hopefully those will arrive in the next few days. I looked into using an MMC card with the arduino and found a library called SDFATlib, which would allow access to files that are PC readable. However, the library takes up a considerable amount of size, so the chip upgrade will pretty much be necessary to run that.

So I guess my next steps here are to create PWM generation code, look into building an ATmega Programmer, and take one last look at I2C.

Yesterday I got the code for transferring multibyte data via SPI working. I ended up using the first byte from the arduino to choose which channel I wanted to get data on, which stored the data on the PIC in a static variable, so I could get read multiple times without the number changing and then sending 0xff to get remaining bytes. It works quite well and I was considering setting it up so the first byte was a command, with subsequent bytes being data transferring back and forth. This would allow me to set the PIC up in different modes and allow it more capabilities than I had originally intended.

I also have a new algorithm for the timer to read multiple channels successfully. However, in it's current form it has some limits. First, I need to set which channels are active for it to work. Second, if there is no data being received from an active channel, the entire thing stops until it starts getting data from that channel. I'm trying to devise a way for it to automatically detect which channels are active upon initialization, but I haven't come up with anything reliable yet, so it has to be set manually. Additionally, the way the timing is working, it appears the first channel is taking just a little longer for timing, but it may just be in how I have the RC transmitter programmed. So my current task is to try and either detect the active channels automatically, or modify the timing algorithm to not require this. Another option would be to add the option to send commands via SPI, so the active channels could be set that way. At this point, I'm very close in getting a first prototype of the robot running.

I got my timer code working nicely. I originally kept losing the the high byte of the timer because even though I bitshifted, my timer variable was only 8 bits, so when I shifted the bits over, they would just fall off the undersized variable. As soon as I started reading into 16-bit variables, the problem went away. When I generated my algorithm, I had assumed that the signals for all 6 channels occurred simultaneously. However, upon hooking up 2 channels of my oscilloscope together I discovered they actually occur sequentially, so as soon as one channel ends, the next one starts. An easy way to fix this is to use one channel's end time as the next one's start time. Now, if I have all 6 channels connected at once, this isn't a problem, but I want to be able to have channels missing and still have this work correctly. One way around it might be to have it detect active channels and check only those. It just gets a bit tough when dealing with microseconds and efficient code is extremely important. So the goal for today is to figure out an algorithm that addresses the new information and possibly to code it in.

I reattached the strut I had repaired yesterday and it seems to be holding up nicely. If it bends enough to need another repair, my next step will be to temper the pin so that it's much less bendable (more like a drillbit).

As far as figuring out the other boards and MMC, I've decided to put that on hold until after I get the timer code working. Also, since I've decided to store the values as 16-bit numbers, I will need to figure out a way to transfer that via SPI, since I've only tried sending 8-bit numbers. In the worst cast I could always send it as a high byte and low byte, but I'm pretty sure that's unnecessary.

I started work on the timing coding. Unfortunately, at this point it's behaving a little erratically. I hooked my oscilloscope up and wasn't able to get any clear reading. So, I decided to try the receiver in the car itself and charged up the batteries overnight. This morning, I connected everything and when I tried to operate it, I had no response. I did notice the car twitched if I shut off the transmitter, so I was pretty sure it wasn't broken. After pulling out the manual, I went through the settings and found it was in QPCM (Quick Pulse Code Modulation) mode rather than PPM (Pulse Position Modulation) mode. After changing it, the receiver responded just fine. I hooked up my oscilloscope to the receiver after plugging it back into my circuit to visually see the waveform and I had been expecting it to be high at idle and going low for a period of time. However it was the opposite, so I'll need to adjust the code to my new findings.

Additionally, I noticed that one of the struts on my car had snapped in half. I was able to carefully drill a hole lengthwise through the plstic on both pieces and fashion a pin out of a large paperclip that held the piece together. I added some JB Weld onto it and am just waiting for a few days for it to dry completely before putting it back together.

I made a diagram of all the pieces that will be going into the first build of the robot. I will need to make 2 or 3 circuit boards with 1-2 of them most likely being single-sided and the 3rd being double-sided. It will have a USB extension coming out of the arduino with a jack on the bottom of the car that will be protected by the battery covering so that I can update the arduino without disassembling the car. I will also be putting in a socket for an MMC card for future use, however I'm undecided about the MMC card being part of the PIC board or it being a separate board at this point. I will also have a board that will fit on top of the arduino and provide connectors to other the boards as well as places to plug in sensors. There will undoubtedly be some changes to the design as I learn more, but the design is definitely coming along nicely at this point.

After a lot of fine tuning and tweaking, as of last night, I've finally been able to get the PIC and arduino to communicate without errors. I've noticed that occasionally one of the shift registers gets it's bits rotated on power-up, but a reset of the arduino seems to fix the problem. I'll still look into that so it can work reliably.

The next will be reading PWM values from the receiver. According to documentation and as I've seen on my oscilloscope, the times should vary between 1000-2000 microsecond pulses depending on the direction of the controls. My plan is to have a 16-bit timer constantly running from 0-65535 and looping back in order to have something to measure time. Also I will be having the PIC running in a loop and taking note of any changed states of the 6 lines it will be monitoring and calculating the length of the pulses. I'll then have it throw out any values out of the expected range. Once I get the measurements I'll use the number to calculate a value between 0 and 255 and store in on the PIC. When the arduino requests a particular channel's value, the idea is to just send the last stored value for that channel back to the arduino.

For testing purposes, I'm also swapping the 18f2620 for it's bigger brother, the 18f4620. It has an additional port (Port D) that I can use for PWM testing while still allowing the LCD screen to be connected. After I get everything working, my plan is to disconnect the LCD (and remove the code for it) and use port B for connecting to the receiver.

I decided to give I2C a last final effort, which included tons of searching on the internet. The problem is that other than the start and stop bits, the interrupts are never triggered. I double-checked so many things and actually found a few things to fix, although it didn't really make any difference with the results.

So after reading about SPI since last night, I was able to figure out the code for the Arduino and get that programmed pretty easily as a master and set it up to send out data every half second. I did some reading about the PIC and got that set up so it initialized and would display some data on the LCD if it received any data. On the first attempt, I was able to start displaying information on the screen. It looks like I'm going to use SPI despite the additional wires/pins it uses because it works. After doing some more reading and fine tuning, the next step will be to get specific data flowing between the 2 and then I'll program the PIC to start reading and storing values from the PWM (remote control) receiver and storing it so that the arduino can just query the PIC chip any time it needs those values. After that, it'll be time to get to the fun part and actually creating the main program that will run my robot.

It's been a while since I updated. I ended up putting the logic analyzer onto a circuit board a while back and it works fine. I was still trying to get I2C working between my arduino and PIC chip, but still have been unsuccessful in even the simplest communication. I set up an LCD display that shows what the 1-byte values of up to 4 registers are. I also set up a second chip to attempt PIC to PIC communication via I2C and even hooked up another LCD display to that one, but after further investigation I'm going to look into trying SPI (Serial Peripheral Interface). SPI is apparently much better supported by PIC than I2C and there is an SPI library available for the arduino, which I've downloaded. So the next step is trying to get some communication going via either the PIC chips or the arduino and a PIC via SPI or even I2C if I can. One big advantage of using SPI however, is that it would allow me to make use of an SD Card in the system for tons of extra space as well as something I could easily reprogram without disassembling the circuit. However, I'm just going to start by taking 1 thing at a time for now.

Well, I ended up building a logic analyzer this morning. I found an older laptop that I wasn't using for anything that had a parallel port and I built a simple analyzer out of a parallel cable. The design on the site called for a 74HC245 chip, which I didn't have, so I substituted it with some other chips based on how it was wired up. I ended up using 3 74LS04 Hex inverter chips and paired 2 inverters per input (8 inputs total) to create buffers, which is all the other chip was used for anyhow. However, I needed +5v and the parallel port was only providing about +3v, so I wired a PS/2 cable in to power the chips. I hooked it all up, tested and it worked (although it's still on breadboard for the time being). I still have much to learn about the I2C protocol, so that's what I'm working on doing now.

Well, not much progress today for the most part. The 2 are communicating, but the results don't seem to be what I keep expecting. This morning, I originally thought one of the chips I had was bad, but it seems they got a little messed up when I tried writing to them without power plugged into my programmer. Doing an erase, a full read, and then a write (with power) seemed to fix it and once I figured that out, I haven't had any problems. This would be so much easier with a logic analyzer, but I don't have one, and I don't have the money to buy any parts to make one (at least not based on the designs I found on the internet). I could probably build one with what I have, but I think it would require a large amount of time spent on that and I'd rather not be side-tracked. I think I ended up spending a large portion of the day trying to get it working while using a reserved address, so I'm having to do a lot of testing all over again. I think overall, I just have a lot to learn about the I2C protocol. I think it will just be a matter of plugging away at this project until I figure out enough things to finally get it working. Fortunately, I tend to be more inventive with figuring out software, than I do hardware and finding bugs is one of my specialties; learning new things like this protocol is one of my other.

It looks like I may have been a bit hasty. I decided to continue working on the project some more and here's what I've done in the last couple weeks and what my plans are at this point. I did end up bonding the bumper together, but when I was working on getting some metal for reinforcements fitted, I ended up snapping the bumper in half, so that's something I need to work on still. I continued working on fixing the breakout board for the dsPIC in case I could get that working. I came up with a wonderful technique (although very difficult still) of repairing the circuit board traces of such small width. I took some scrap pieces of wire that were left over from a null modem cable I made this past week (for a Sun Server I had aquired and finally got around to getting it up and running). From that wire, I used one filament of the stranded wire, which happened to be about the width of the trace (I had to do this under a magnifying glass), and soldered it along several of the traces. Unfortunately, about 25 of the traces were in need of repair and I still have about 5-10 more to do. I ended up giving up on that for now and went back to the arduino and PIC chip that I had settled on.

I'm currently in the middle of getting the 2 to talk via I2C. I've been having to do a lot of reading on the implementation for both circuits (the arduino is much simpler). With the PIC chip, when I was trying to write the program onto it, I started having difficulties with intermittant errors. Keep in mind that I had a breadboard with wires plugged from various pins on the chip to the socket in the programmer since it was originally made for 18-pin chips and I only had a 40-pin adapter. I discovered that if I plugged the wires in via the 40 pin adapter, it worked perfectly since it had a couple resistors and capacitors on it (which I can't remember is hooked up to what). Because of the inconvenience of the wires, I went ahead and built a 28 pin to 40 pin adapter that attached right on top of the other adapter since the pinouts for the 28-pin chip were almost exactly the same as the 40-pin chip. So, this is where I leave off tonight. Hopefully I can finally get I2C communications working tomorrow.

I've put the work on hold for the most part at this point. I'm currently working on repairing the body of the car from the crash. Currently the front bumper is mostly intact using JB Weld to hold it together. After that, I plan on reinforcing it with metal so that it can withstand an impact again without crumpling. As for the electronics, I'm holding off on working on that for now while I get some other things done in my life.

I changed the code so that it blinked a bicolor LED between green and red. It was having trouble and operating erratically. First I tried programming a second chip with no success, and then I ended up mounting all the components on a different breadboard. They seemed to work much more consistently on the new board. I'm now at a point where I'm doing more reading so I can start making use of the timer. Once I get that figured out, I'll work on getting 1 channel read and change the light between red, green, or both depending on the position of the control. After that, getting multiple channels working should be much easier.

After doing some reading, it sounds like I2C will fit the bill after all. Hopefully I'll be able to make some more progress on this over the upcoming weekend.

I made some progress tonight. I've been doing a bunch of research on various settings for the PIC18 series chips such as what the various fuses are and how to get it to run with the internal oscillator and use PLL (phase locked loop) to multiply the clockspeed by 4 to get a total of 32MHz. I had thrown together some code last week and uploaded it to the chip, but when I tested it, the LED didn't seem to blink. When I tried the program in a SPICE simulator, it seemed to run ok, so I wasn't sure what was wrong. I fixed my power supply, from which the voltage regulator had been resoldered numerous times had finally detached for the last time, by simply replacing it and wire-tying it to the board better. I hooked up the circuit and still it didn't blink. I couldn't locate my logic probe to test it, so I decided to try hooking it up to my oscilloscope. I was pleasantly surprised to see a square-wave pattern on the screen. What had happened was when I threw the test program together, I made a delay routine that just simply ran from 1 to 10000, which was simply too fast to visibly show up on the LED. With a bunch of testing and using the "stopwatch" portion of MPLAB, I was finally able to make a fairly accurate delay routine, which now works. I'm working on making the pseudocode (which is nothing more than a step by step description in english about how the program runs) for a program that will decode the PPM signals from the receiver and somehow transmit them back to the arduino (either via I2C, SPI or possibly analog output). I just love the irony of having a project that uses a PIC chip and an Atmel chip (2 major competitors) together.

Last night I found a copy of the C18 compiler I had downloaded, copied and pasted a sample program into mplab and compiled it successfully. After that, I uploaded it to the chip successfully, erased my buffer, and read it back from the chip successfully, so my adhoc adaptor is working fine. Just FYI, my adaptor is just a breadboard with wires going to my programmer on corresponding pins for Vcc, Vss, MCLR, PGD, PGC, and PGM. At least it gets the job done. The next step is to get a program I had written for the PIC16F84a ported to the new chip and updated so it can be read via I2C. Once that's done, I'll probably make a custom circuit board that allows me to just plug in jumper wires from the receiver to the chip and have another set of jumper pins to communicate with the arduino via I2C. After that, writing a control program for the arduino should be quite easy assuming everything works as planned. I'm not sure if I already mentioned this, but there were 2 main reasons I am using a separate chip to read the pwm signals:

  1. It can be processor intensive to read the data and I'd rather have a dedicated processor for it.
  2. The arduino has a limited memory and I didn't want to waste it on code to read the PWM.
With the dsPIC chip, it had settings to automatically read it without extra code or processor dedication, but because the spacing of the leads is so tiny, making a circuit board becomes very difficult. I also have a feeling that if I can make a circuit that translates multiple PWMI2C signals into I2C, I may end up with a product others want, since I have seen a lot of demand for it, but have not come across any such products.

Ok, it's been a while. I've been doing things like being in a musical, playing World of Warcraft, and learning the violin that have been taking up much of my time. However, I've made some progress on my robot. First of all, I've decided to go with an Arduino Diecimila board for the main controlling board. I had attempted to create a breakout board for the dsPIC processor, but my boardmaking skills just don't seem to be good enough. Sure I could order custom boards, but that gets expensive. Anyways, the arduino was only about $40 after shipping and everything. I chose this because it's a popular platform with a lot of code available for it and there's nothing to build for the main unit. I also purchased an oscilloscope, so that should help me with reading signals.

I've been playing around with how to get everything set up and I did lose a bunch of my diagrams, but I do have a lot of stuff in my head still. My current decision is to use the Arduino as the main board and for reading the PWM signals from the RC control, I'm going to use a PIC18LF2620 chip with some custom code and will communicate the values to the arduino via I2C. This is a 28 pin chip, so it's relatively small and I already have it. Also, it's in a DIP package, so it's easy to prototype with breadboard. My main challenge will be throwing together an adhoc adaptor to my programmer since it only does 18 and 40 pin chips, but I don't think that should be too difficult. I'll post further if I make any additional progress. The next step is to get the PIC chip working.

Ok, I put together an adhoc adaptor for the PIC chip on a breadboard with wires and tested an initialization and that seemed to work. The next step is to write a simple test program and see if I can write it to the chip successfully. I need to download and install the Microchip C18 compiler to do that and I'll probably take care of that tomorrow.

I didn't do too much this weekend. I ended up putting the shell on and raced the car around again with my boyfriend. I also drew up a circuitboard design for the breakout board. So the next step is creating and assembling the circuitboard. Then once that's tested, I can figure out how I'm going to go about with programming it for the time being. I'm hoping I can just connect it to my existing programmer by building some kind of interface. After that I can start breadboarding out the actual circuitry. I also need to find a high-level block diagram I drew up for how the circuit will interact, although I'm pretty sure I could figure it out again if I had to.

I went ahead and bought the remainder of the parts although I ended up needing to stop at 2 Radioshacks to get everything. I went ahead and put together some wiring adapters and finished hooking everything up. I recalibrated the steering and had to reverse the direction of the ESC through the remote, although I could have simply switched the colored wires. I used velcro to hold the battery cover in place and after putting the cover over the electronics and securing the extra antenna wire, it was ready to go. So I went ahead and took it outside to get an idea of it's capabilities. It raced just fine and was able to go very far. In fact, I was only limited by how far I could see the car. I think it went around 10-15 MPH by comparing it to other (real) cars going through the parking lot. Unfortunately about a minute or two into starting racing I crashed into a pole and snapped the front bumper into 3 pieces, which is mostly cosmetic anyways. I was able to race it up curbs, on grass and accidentally went through a puddle a time or 2. The only thing that stopped it was if it crashed into some bushes, which caused the wheels to become jammed in the branches from the inertia. All in all I'm pretty happy with the car. I think it's probably the best one I've ever had. The next steps are going to be fixing the bumper and starting on the main robotics board, which will probably start with me making a breakout board for the processor, which hopefully shouldn't be too challenging. I also took a bunch of pictures available for viewing below.

View Robot Photos

Last night, I went ahead and bought an ESC and a new battery. The ESC was quite a bit cheaper than I was expecting at only $30. I got a new battery because it was a NiMH (Nickel-metal Hydrite) and had a much bigger capacity 3000mAh (milliAmp Hours) over my old NiCd battery with only 1200mAh although they had batteries with capacities up to 5000mAh. I also discovered a hidden battery compartment for the old circuitry that could hold 4 AA batteries, although I don't currently need it. I may make use of that if I feel it could be beneficial to any additional circuitry. The ESC was able to provide power to the receiver as well as the servo, so that was a definite bonus since I won't need the AA battery pack that came with the receiver. Also, it looks like the ESC has very low resistance and a small footprint, so I see little benefit in building one myself.

I went ahead and soldered 2 wires together inside and insulated it with heat shrink tubing that I had bought and then secured the receiver inside with some velcro. Then I desoldered the switch from the ESC and soldered a bigger one that came with the car so it would fit inside the switch compartment. Then I straightened out a bend in one of the front tie rods (probably from the previous owner) and reattached the front bumper. At this point, I need to buy some bullet connectors, heavier gauge wire and some method of securing the battery compartment door since the tabs have been worn down over time. I figure I can use velcro for that. I'll head over to Radioshack later today to get those items (they should have all of those things) and then I can finish assembling the car tonight and recalibrate the steering so that I can at least get it running as a basic RC vehicle, which is excellent for the summertime.

I also was looking into the costs for a real ICD and what a development board would cost and the prices seem more reasonable to me--especially on ebay. I may get those eventually if I can't get my ICD clone working.

Ok, here's what I did last night. I started trying to design the new circuit and realized I would need some kind of transistors to drive the motors, so I decided to go a different, but easier route. I checked the value of the potentiometer inside of the pseudoservo and it tested at 5K ohms. Then I took apart my existing servo, and did a little testing. Inside the potentiometer was reading at 2.6K ohms, but I figured it might have another resistor in parallel, which would drop the resistance, so I desoldered it from the circuit board (after carefully diagramming it) and retested the potentiometer. It tested at 5K ohms this time. So I went ahead and put the circuitry from my existing servo inside of the pseudo servo, so now it's a real servo. I reassembled the car and tested and it worked although I do need to recalibrate the remote for the new mechanics, but this should be a very good solution. I may build that circuit for my old servo in the future anyways because it would be a neat circuit to have available.

The car I got is a Nikko Super Megatron which was manufactured under a number of other models as well. One of them was manufactured for Radioshack as the Desert Viper (I looked at a parts diagram to confirm this). I remember that particular car from when I worked there 12 years ago and it was their most expensive car and if I remember correctly, it went for about $225 at the time.

One of the main reasons I liked going with this new chassis is that it held a 7.2V batter as opposed to the 9.6V one I had in the truck. Most of the commercially available ESCs (Electronic Speed Controllers) would only go up to 7.2V, so this gives me a much wider variety of to choose from. The next things I am going to try and get are a commercial ESC and a new battery (the one I have is probably at least 15 years old and I haven't used it for that long either). Then again, I successfully used another 9.6V battery that was about just as old, but it doesn't hurt to have 2 batteries. This should give me enough parts to get a basic RC car up and running.

The next step would be to start making logic boards for the brain of the robot. I have been toying around with the idea of just buying a commercially available board with a chip of my choice as well as a bunch of support circuitry. That way I could just take care of the programming, which is the portion I am looking forward to the most (although I do love the challenge of getting things working mechanically). However, if I do end up going with my own design, I think I will start by creating a breakout board for the processor (a circuit board to which an SMT chip is soldered so that wires can be connected to each separate pin of the chip). That way I can just hook it up to a bread board and develop a much better understanding of how it need to be hooked up as well as to be programmed. In fact, I could most likely just hook up the processor on the breakout board directly to my existing programmer. I still don't feel like mucking with an ESC at the moment, but if I feel I could build a more efficient one, I may go that route after getting the initial car running.

It's been a while since I updated this page. Since my last entry, I made many design changes. First of all, I decided to go with a dsPIC33F device that is specifically designed for motor control. It has many nice features that would make future expansion of the robot very simple. However, in order to use it, I need to have an ICD (In-Circuit Debugger) to program it since making some kind of adapter for my programmer would be impractical and the ICD allows debugging straight from the software, which is very nice. I went ahead and built a USB version of an ICD clone, but when I attempted to plug it into my computer, the lights lit up, but no new device was detected. I compared my circuitboard to the original schematic and found a couple design bugs, which I fixed, but it's still not working at this point. I wonder if I may have fried the USB chip when removing it. I do have another one and I probably should have tried breadboarding this before making it, but oh well. That portion is on hold for now.

Recently this past weekend, I had stopped by goodwill and found a Nikko 4WD car (I can't remember the model) that came without a remote or battery for only $6.99, so I bought it. I am now going to use this for the chassis. It's much bigger than my truck and looks more proportionate to my remote control size. The motor that controls the steering is basically a pseudo servo and has a potentiometer and a motor inside with some gears. I am working on designing a simple circuit that will read the PWM signal and control the position of the motor based on it's value. For that I'm going to use a PICF628A which has all of the basics I need. I should be able to get this circuit working in the next few days, which is extremely simple. I have more to update, but I need to get going.

Ok, so here's what I did this past weekend. I started by working on the steering. To start with, when I loosely put the old parts in, I realized there was a new problem. The servo has a larger turn radius than the old motor. So, I needed to redesign how the steering worked somewhat. I decided to go with a steering method similar to what was originally in the car. The first step was to figure out how long to make a lever to make use of the turn radius of the servo in order to get the full turn radius of the wheels. I did a measurement or how far a know lever turned on the motor and using tangents, I calculated the angle the servo turned (approximately 120°) as well as how long of a lever I would need. Then I redesigned the bracket in my head and fabricated it out of brass using a variety of tools. I also designed and created a new linkage, while making use of the existing tie rods for the wheels, and assembled the whole thing. I gave it a test and it worked pretty well, but the only thing I'm not too happy about is that it has a bit more play than I would have liked, since I didn't have a good way of making it easy to disassemble while securing the tie rod to bracket linkage from rotating. I may go back at this and build an improved version with better leverage that addresses the looseness problem. Also, the weld stuff does hold to metal quite good, so I'll probably make better use of that as well. It's good enough for now though and the steering does actually work for all practical purposes. I took some pictures of the linkage, but have yet to upload them.

The next thing I tackled was seeing if the rear drive motor could be upgraded. I bought a larger DC motor at Radio Shack and decided to test it's RPM on the same load and voltage as the old motor before doing a replacement. I took another motor to use as a generator and connected a gear to it. Next, I hooked up my multimeter to the generator motor to measure the voltage output. Then taking each of the motors and connecting the same gear to them, I tested how much voltage each generated when turning the generator. Surprisingly, the original motor produced more power, so I decided not to make any modifications to the rear of the truck. I reassembled it and used some epoxy to make a couple repairs while doing so, since some plastic parts that had snapped off in some crashes which probably occured when one of my kids was driving it.

Next I started looking at electronic speed controllers designs again. My biggest worry was how I was going to read all the radio inputs into the microprocessor. Most of the designs which used a pic chip read no more than 2 channels for reading the PPM (Pulse Position Modulation) value to determine what positions the controls were in. Since I wanted to make use of the 6 channel RC Transmitter/Reciever that I had, I was looking at various ways to tackle this. One that I had been considering was assigning the task of reading the PWM (Pulse Width Modulation) signal with separate pic16F84a chips and communicating information back to the main pic16f877a processor, but I wanted to see if I could find a simpler solution. After doing some research, I'm thinking of making use of an octal latch chip (such as the 74LS373) to latch in the values of all 6 channels and loop through them, which will allow me to make calculations to determine the pulse widths on all channels without channel values changing during those calculations. Then I could make use of just the pic16F877a without complicating the design too much with a bunch of other unneccesary extra parts. That will also keep my costs down and it's much easier to make software tweaks using 1 microprocessor than multiple microprocessors.

Since I have somewhat of a good idea about what I'll be doing with hardware, I'll be writing the initial software soon. For the test circuit, I'll probably do something low power like rapidly blinking an LED or 2 to give it the illusion of changing brightness as the controls move. Either that or I may just output something on an LCD display, for which I wrote some nice code to interface it about a week and a half ago.

Most of my work up to this point has been research, collecting tools, and getting some code working for the microprocessor. I also took the original 27MHz circuit board and diagrammed a schematic out. A few days ago I started implementing the mechanical changes and upgrades to the truck. I ordered some books on robotics to help out with some of the details as well as to provide an easy reference if I need it. I've been able to do more work on it lately since I was off work to recover from having gallbladder surgery.

So far I have taken the truck apart down to small pieces and started the replacement of the front steering. It was using a motor with gears and a small circuit board inside that provided feedback to the controlling circuit so the motor would stop when the wheels were turned. I took that apart and removed all the gears and motor and used a Dremel tool, a drill, and some files to be able to fit the servo inside the old motor casing. My challenge was to place the servo inside the truck in such a way that it would require no modification to the servo itself if I ever needed to replace it. After carving it up, I used electrical tape to secure the servo from shifting around inside. Then I took one of the metal gear posts from the original parts I removed from inside the casing and secured the post in a location so the new unit would still fit into the truck in the same way the original motor component did. So that fits into the car well and lines up just right.

Now I am working on designing and creating a bracket so that I can attach the old linkage that controls the wheels to the servo without modifying the servo at all. I have a general design in my head at the moment, but I am testing some of that liquid welding stuff between the 2 different metals I am going to use. I applied it this morning and it's currently drying. If all goes well, then making the bracket will be simplified. Otherwise, I'll just come up with an alternate design. So the plan is to get the steering functional this weekend. I'll also be working on a design for the speed controller and I may order some parts to be able to create that. I've found a couple of good designs already, so I'll most likely be using those as a base. I also found a good design for an H-bridge online, but I'll need to look that up again since I forgot where it was (although I think I remember). Hopefully I'll be able to at least get the truck running as an RC truck with digital proportional steering in the next few weeks. Adding sensors (such as an IR sensor) shouldn't really be all that difficult and there's supposedly a good design in one of the books I bought as well as some designs that I found online.