Status
2007.06.28, Thursday, 15:22
Here’s a photo of the (almost) fully-assembled Ichibot. The LCD panel will be bolted to the top plate, but I need to pick up some M2 screws.
It’s larger than I want it to be, primarily because of the large size of the Make Controller application board.
2007.06.27, Wednesday, 13:20
I’ve made lots of progress. I’ve rebuild the motor platform several times, using the absolutely fabulous TechShop. I can finally experiment freely with different mechanical designs. I’m finally in a position to start developing software. I’ve got a crude Kalman tilt estimator that I’ve hacked together on a MakeController. I plan to develop an custom application board for it, but for the time being I’m using the supplied one.
Here is the one photo I was able to take before the battery in my camera died. The plastic cups are just for support (it can’t rest upright). Click the image for a larger version:
2007.03.18, Monday, 19:23
Looking at the motor data sheet, I’ve gleaned the following information for the Pittman motors I’m using:
| Model | GM8724S021-R1 | ||
|---|---|---|---|
| Reduction Ratio | 60.5:1 | ||
| Gearbox Efficiency | 66 | % | |
| Gearbox Length | L2 | 24.6 | mm |
| Length | L3 | 83.4 | mm |
| No-load Speed | SNL | 17.6 (168) | rad/s (rpm) |
| Continuous Torque | TC | 18.5 X 10-3 | N· m |
| Peak Torque | TPK | 118.6 X 10-3 | N· m |
| Motor Constant | KM | 710.5 X 10-3 | N· m/√W |
| No-load Speed | S0 | 1064 (10158) | rad/s (rpm) |
| Friction Torque | TF | 2.5 X 10-3 | N· m |
| Rotor Inertia | JM | 1.62 X 10-6 | kg· m2 |
| Reference Voltage | E | 12.0 | V |
| Torque Constant | KT | 10.9 X 10-3 | N· m/A |
| Back-EMF Constant | KE | 10.9 X 10-3 | V/rad/s |
| Resistance | RT | 1.17 | Ω |
| Inductance | L | 0.58 | mH |
| No-load Current | INL | 0.36 | A |
| Peak Current (stall) | IP | 10.3 | A |
Torque/current curves:
Dimensions:
Encoder connections:
| Pin 1 | Black | Ground |
|---|---|---|
| Pin 2 | Green | Index/NC |
| Pin 3 | Yellow | Channel A |
| Pin 4 | Red | Vcc (5 V) |
| Pin 5 | Blue | Channel B |
2005.07.03, Sunday, 00:34
Okay, so I lack focus. Too many projects. School and work, whatever. I’ve finaly gotten most of the parts for the new base constructed. I used EMachineShop to make the motor mount brackets, and found EPPCO, a local Berkeley machine shop, to do the axle block.
|
|
| Assembled base three-view | Assembled base overhead (actually underneath) |
|
|
| Side view | Drive train closeup |
|
|
| Drive train overhead view | |
2005.03.05, Saturday, 18:29
Wow, it’s been a long time! But in an ongoing effort to avoid studying and homework, I'm mucking about with the Ichibot and associated pages.
Even though I haven't gotten very far with Ichibot, I’ve decided to build a new, better mechanical platform for it. I’ve designed the chassis, and am currently looking for way to get it machined. I’ve also purchased the necessary hardware, pictured below (click the images for a larger version, or the links for a huge version).
|
|
| Full-sized image of separate parts | Full-sized image of partially assembled parts |
The new Pittman motors (part GM8724S021-R1) are much better than the old JameCo motors. They are 12 VDC motors with 60.5 : 1 reduction gearheads and 500 CPR encoders. They were $195 each, and I’m a little concerned that I ordered too much gear reduction. Some people on the robotics lists have all suggested I’ll be happy to have the torque, and that the output shaft speed is sufficient. We’ll see.
The new chassis will look something like this. I need to redo the CAD. I’ll post complete drawings and make the files available.
2004.02.18, Wednesday, 18:10
Yesterday I added training wheels to the bot and allowed it to run free in the kitchen. The “training wheel” is a simple furniture caster attached to a 1.5" wide piece of aluminum bent in two places and bolted to the frame. The controller is running a very simple navigation program. It basically goes forward for two seconds, turns right for one, repeat. The timing is too far off to make any kind of recognizable shape, but it was a chance to see the ’bot in action.
There’s also a short high-power burst forward and backward (and forward again) to qualitatively determine what kind of torque characteristics the system exhibits. Interestingly, it’s enough to kick the caster wheel up off the ground, despite having two battery packs strapped to it.
For its first untethered tests, I added two 6-cell, 3000 mAh NiMH battery packs (the kind used in electric R/C race cars and planes) wired in series to give a nominal battery voltage of 14 V. This makes for rather large drop across the controller’s main regulator (and might even be outside the spec; I’ll have to take a look). Perhaps I should tap off of one of the batteries for powering the electronics.
2004.02.16, Monday, 02:04
What a crummy day. I spent so much time fiddling with the LCD code that I broke. I had started writing a basic PD speed controller. I was writing a fair amount of info to the LCD during the PD loop interrupt, which was taking quite large portion of the available executiong time, so I tried to tighten up the LCD code (more details in a later post). Well, I broke it. Many, many hours later, and after fixing it and having it all of a sudden stop working multiple times, I got it and the PD code working.
Now, I based this off an old article written by David Anderson. It does something interesting. If you command a speed of zero, and then turn a wheel by hand, it will resist that effort like a spring. If you then release the wheel, it will rotate back to its approximate starting point.
The calculation of the PWM signal is cumulative, even if there is an error of zero, so the PWM is being integrated (I think). I need to brush up on my understanding of PID controllers to figure this one out.
2004.02.15, Sunday, 00:18
The pages are all now valid XHTML 1.0. There’s a link at the bottom you can click to validate it for yourself (the XHTML Valid logo).
2004.02.14, Saturday, 21:57
Okay, I’m a dork. I made so many mistakes trying to figure out this serial communications thing, it’s not even funny. But, I’ve got it working now.
Two major things went wrong. First, I failed to realize that the ’32, by default, operates off of its internal 1.0 MHz oscillator. You have to program clock selection bits as a separate step to get it to use an external crystal (which I had connected, but didn’t realize wasn’t being used). Since all of my baud rate calculations were being done assuming a 4.0 MHz clock, they were way off (which explained the bizarre timings I was seeing on the TX pin).
Unfortunately, try as I might, I still can’t seem to get the external crystal to work. I’ve succesfully driven a PIC16F877 at 20 MHz on perf board, so I’m not sure why I can’t get the ATmega32 to run at 8 MHz.
So I punted on trying to get the crystal to work, and configured the MMC to operate at 9600 bps instead of 38.4 kbps (the ATmega32 can’t drive a serial line at 38.4 kbps with less than 8.5% bit-rate error, and that may be too much for the MMC). After much futzing with this speed, I still couldn’t make it work, which brings us to my utter stupidity: the MMC wasn’t fully seated in its socket, and so wasn’t actually getting the signal!
It’s working for now, and so I’m going to spend some time actually writing software. I’ll write code to run the motors at a constant speed, regardless of load (within limits), and then drive the bot around in a small square or triangle. It won’t balance, so I’ll add a stabilizing caster wheel, but it will give me enough of a platform to work on that I can develop a basic PID controller.
2004.02.13, Friday, 20:43
The reorg is well under way. Some of you may experience issues with the rendering. All I can say is, “get a better browser!” In general, I’m using Safari, and only occaisionally testing on IE/Mac 5.2. Windows users, well you can just fend for yourself. Sorry!
2004.02.13, Friday, 01:35
Got the second wheel encoder hooked up, and replaced the other wheel. I also hooked up the MMC, but for whatever reason have not been able to get the serial communication between it and the ’32. I can see the pulse train on the ’scope, but the MMC fails to recognize the transmission.
2004.02.12, Thrusday, 00:41
Outstanding success! I figured out the problems I was having getting PORTC’s pins to Respect My Authoritaaa…
Turns out that JTAG is enabled by default on this device, and for some reason disabling JTAG internally didn’t work. I tried writing the bit by assigning it twice in succession in gcc. Instead, I changed the fuses to disable JTAG, and that cleared up the problem.
An interesting side note about how I realized it was the JTAG settings getting in the way: I was thinking that perhaps some alternate function of the PORTC pins might be getting in way, but it didn’t dawn on me which function until I ran a simple sequential count on the pins in fairly rapid succession, using the STK500 LEDs to show the output. Lo and behold, only the least- and most-significant two bits changed state. Checking the docs, sure enough, the remaining bits were all dedicated to JTAG.
Once I got PORTC in order, I reconnected the LCD which I had wired up a couple nights ago. It worked like a champ, with the otherwise untested code I wrote then. This image shows the LCD displaying my friend’s name and the current encoder count (more on that below).
After the success with the LCD, I couldn’t resist getting at least one wheel encoder working. So I took a stab at setting up an AVR interrupt handler, set a few configuration bits, enabled interrupts, and presto! It worked.
I’m taking this approach to the quadrature decode: I feed the “A” channel from each encoder into one of two interrupt-generating inputs on the ’32, which is configured to interrupt only on rising edge transitions. Then, in the interrupt handler, I check the state of the “B” channel for the corresponding wheel, and if it’s low, I subtract one from a 32-bit counter, otherwise I increment the counter.
A little impromptu testing (marking the tire, counting a few revolutions forward and the same number back, should get a result count close to zero) seemed to indicate very little error (no missed counts) using this scheme. There’s enough resolution in this encoder that it registers a step even in the play present in the gearbox.
Another check was to see how long the ’32 spent in the interrupt handler. The image below is a shot of the oscilloscope. The top trace indicates the low-to-high transition of encoder channel A, and the lower trace roughly indicates the time spent in the interrupt handler (I set a pin high first thing in the interrupt handler, and clear it as the last step before returning). The handler is much faster than the encoder half-period, and this is only on a 4 MHz prototype. (The larger image has some annotations).
Okay. It’s very late, and I’m going to pay for my stubbornness in the morning. Here’s an image of the bench after tonight’s fun. The colorful board is the STK500.
2004.02.11, Wednesday, 19:56
A bit of reorg is underway; sorry for the broken links for the duration.
2004.02.10, Tuesday, 20:35
A couple days after I bought the Basic Stamp, my Atmel development kit arrived, pretty much destroying any hopes for the poor Stamp to be a part of this project.
I set up the STK500 and the pre-programmed AT90S8515 started pulsing an LED on the board. Then I installed the AVR gcc toolchain on my PowerBook, and a couple of hiccups later (you have to explicitly erase it before programming), I was writing C code and watching LEDs blink. The AVR gcc toolchain worked very well on Mac OS X, but I did have to make a minor change to one of the include files to get it to compile for the ATmega32. Targetting the AT90S8515 that came with the STK500 worked without modification.
I’ve started building a new main board around the ATmega32 controller. I cleaned up the layout and added some LEDs to give status info. In the picture below you can see the PIC16F877-based board on the left, and the new board on the right. The new parts placement should allow marginally better cooling (the fins of the MMC heatsink are now aligned with the primary direction of the airflow when the bot is in motion). I also superglued most of the components down before wiring, which helps keep them in place as I work on it.
The board on the left is still populated with the PIC, Solutions3 Motor Mind C module and Analog Devices linear accelerometer.
The board on the right is a little farther along than is shown in the image. I've wired the LCD header (in the lower-right) as a first step, but I'm having trouble getting the AVR to actually output onto PORTC what I've specified in the code.
Since Capilano finally came out with a Mac OS X version of DesignWorks, I’ll probably get a real board designed and fabbed in the next couple of weeks. I have a couple of ATmega128 parts which have, among other things, two USARTs, and a couple more I/O ports. Since one USART is used for communicating with the MMC, it’ll be nice to have the other one for relaying data back to a host computer for analysis.
Now, it’s time to do homework. I’ll try to write more soon.
2004.02.03, Monday, 00:53
I haven’t worked on this project much for the last six months. Between full-time school and a full-time job, it was really very difficult to spare time for anything else. Having made this project into a priority for my eductional efforts helps me to justify working on it.
Given the difficulty I’ve run into getting a C compiler for the PIC to work on Mac OS X, and taking the advice of a friend, I’m going to switch from plans to use a PIC18Fxxx to instead using an Atmel AVR. There’s an open-source toolchain that works on Mac OS X and includes gcc. I expect the programmer and chips to arrive on Wednesday.
In the meantime, I’ve discovered the Parallax Basic Stamp. I don’t really intend to do too much work in Basic, but thanks to the availability of the very nice MacBS2, I bought a BS2p40 from JameCo and had it blinking an LED in under an hour (including the time it took to make a serial cable).
We’ll see if I can make it interface to the MMC and inertial sensors; it has no A-to-D converter, so I’ll either have to add one, or find some alternative. I don’t know what peripherals are available on the SX core used in the BS2, and I really don’t know if it will be fast enough to do all the necessary things.
I’ve added some shots of the ’bot so that you can see there’s more to it than just some beautiful hubs & tires.