Okay, so this lab might seem trickier than it really is. There are only a few things to really watch out for:
First and foremost, you'll need to get your chip working. It's exactly the same as making your microcontroller board in the beginning, except easier.
Instead of adding an external oscillator/crystal, the ATtiny85 will just use its own PLL (phase-locked loop; an internal oscillator that's 'close enough').
Your microcontroller 'cheat sheet' also includes the ATtiny85 (upper-left corner, the one with only 8 pins), so you can refer to it for connections. Much like the ATmega328 (the processor in your Hackduino), this will run just fine in the mini-breadboard if you prefer not to solder.
Connect the GND on the ATtiny85 to the GND on your hackduino, and the VCC to VCC (again, refer to the cheat sheet). Note that, in addition to the notch to show you which way the chip goes, there's also a small 'dot' on Pin 1. You shouldn't need to connect the 'reset' pin, since the chip will lose power when you unplug the 9V from the Hackduino anyway.
For the rest of the connections, just follow the lab.
If you're reading the lab (it's a lot of text, I realize), you'll get everything connected easily. However, just a quick background on what you're doing and why.
First, the purpose of the ATtiny85 is to act as the 'brain' for a 'smart sensor'. That's not an official term of anything, just a description. The sensor is going to count the 'ticks' generated by the wheels. Whenever the main device (your Hackduino) wants to know how many ticks have passed since the last query, the sensor (or the ATtiny85) will give up a number and then reset its own internal tallies back to zeroes.
That communication happens over the I2C (or TWI) protocol, as you saw in your first assignment. Specifically, under the official terminology, the Hackduino is acting as the master, and the ATtiny85 as the slave. This means that the sensor waits for a request, and serves up a byte when asked to do so.
The wiring is explained in the lab, and it's pretty easy (only two wires). One thing to remember is the pull-up resistors (4.7K).
Why? Because the I2C protocol works by having the wires held high. When either end of the connection wants to say anything, they do so by bringing it low. So, point is, just add 4.7K resistors to connect the I2C clock and I2C clock wires to VCC (5V).
The lab explains this. It's pretty easy. You may have already installed the encoders in a previous lab. Just remember that their own VCC is also 5V (from the Hackduino/sensor VCC; not the battery pack for the motors).
Okay, so this is the most important part, right? Ideally, you should be able to get data from the sensor pretty easily. There's an itty-bitty dummy program at the very end of the lab you can use for that. At first, if you just run it, you'll keep getting 0. That's because the wheels aren't turning. Give one (or both) of them a little turn with your hand while the program's running, and you'll see the number change, and then return to zero (after you stop turning them).
So then, how can we interpret the data? The numbers you get might seem a bit random, depending on which wheel you turn, and how fast.
In fact, try turning one wheel just a bit, and wait, and then repeat it. If you see numbers like 1 or 2 popping up, great. If not, try the other wheel. Depending on which you have connected to which, one wheel will correspond to the least-significant bits, and the other will correspond to the most-significant bits.
From here on out, I'll just assume that "left=least" (meaning "right=most"), and realize that you may need to swap them for yours (or you could just swap the encoder data wires to make that be the case).
The sensor will only send one byte at a time. Specifically, an entire reading, across both encoders, is packed into a single byte.
How? Well, we have 8 bits, right? 4 bits correspond to one encoder, and the other 4 match up with the other.
4 bits constitute a nybble. As mentioned above, I'll be assuming the 4 least-significant bits (or Least-Significant Nybble/LSN) is for the left encoder, and the MSN is for the right encoder (and if that isn't the case for you, just flip it around in your head).
An unsigned nybble allows for values from 0 to 15 (0000 through 1111).
If it's been a while since you've used binary:
| MSN | LSN | ||||||
|---|---|---|---|---|---|---|---|
| 8 | 4 | 2 | 1 | 8 | 4 | 2 | 1 |
Of course, your Hackduino doesn't know it's actually getting two nybbles unless you code it with that knowledge, so it'll look like:
| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
What you're going to need to do is to split them up. Let's start with the LSN:
Assume we already have a byte (and if you entered the trivial program at the end of the lab, you do: byte c.
What we want is the last four bits of c, right? For that, we can do a bitwise and:
c&15 (or c&0x0F)
Of course, you can either use the result directly, or assign it to a variable, etc.
This one's a little trickier. Of course, we could bitwise-and with 0xF0 (or 240), but while that would limit you to the bits you want, they're not exactly in the right place, eh?
For example, if you ended up with 208, that doesn't make it immediately apparent that it's for the bits of 1101→13. So what do we do? A bitshift:
c>>4
Note: if you don't want to worry about signs, leading 1's, etc. you might find it safer to still mask it:
(c>>4)&0x0F (or (c>>4)&15. Same difference)
Just to tie this back into where we started, and what the lab explains, suppose you get a byte from the sensor, and you split it into two nybbles yielding the values of 3 for the MSN and 4 for the LSN.
That means that, since the last time you asked the sensor, the right wheel had turned 3 ticks, and the left turned 4 ticks, meaning we've advanced just a bit and turned (slightly) to the left.
Note that, for this lab, you're going to need to travel much farther than 15 ticks. But that's where the sensors max-out, right? Yes and no. The sensors can only deal with up to 15 ticks per query (so check frequently to avoid missing data!). However, you can still have overall tallies in your microcontroller that can sum up the results of multiple queries.
e.g. maybe you want to go 500 ticks per line. Then just keep querying and adding until you get up to 500.
If you want to go a straight line, the best way is to tweak the speeds of the wheels to keep the total distances travelled by each wheel constant. However, that is not required for this lab. Technically, you can actually probably get away with just using one encoder's values for the lab.
Your task for this lab is ostensibly to make it roll in a rectangle. Practically speaking, that is not going to happen.
Besides little details like keeping the two wheel speeds consistent, and imperfections in the tires, the encoders only track the wheels, rather than the motors. That means the precision is not very high (it's the difference between a dozen or so ticks per revolution vs a couple hundred ticks per revolution).
Basically, rather than the actual pattern (rectangle, polygon, star, etc.), just focus on reproducing approximately the same lengths of lines. The angles really don't matter.