My First EEPROM! (Test 3, with wheels!)

With much help from my LMR homies, I have figured out i2c and EEPROM's!

This is just a little video of my first test. Oh, the possibilities now that I can record data!!

***The third video is a little choppy, sorry. --Friggin' Youtube and their damn compression!

Just a test

  • Actuators / output devices: 8 LED's
  • CPU: PICAXE 40X1
  • Programming language: Basic
  • Sensors / input devices: Trimmer Pot

This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/my-first-eeprom-test-3-with-wheels

Very nice Chris, great vidio

Very nice Chris, great vidio :smiley:

Thanks for sharing

Is that the 4 chip board?
Is that the 4 chip board?

Yup.
Yes it is indeed the 4 chip board and I ADORE this board! It has everything all on one board. Unfortunatly you can only get it from one place. And that place shall remain nameless as they have screwed me many of my LMR friends. R4 Systems doesn’t sell them.

hmmm, it must be the same

hmmm, it must be the same place I got my 28 project board (AMC?)

I guess I’ll be carefull with them :frowning:

Baddaboom baddabing - nice -

Baddaboom baddabing - nice - thanks for sharing Chris.
So what are you going to record now ? How about make an arm with POTs at the joint, kinetically move it, to do what you want (teach it) then replay?

All this uController stuff looks fun!

Way to go!

That was a pretty involved intro to I2C, and looks like it is going great!. I was just happy to read some data from a compass I’d tried the first time.

 

…could be used to record

…could be used to record your handwriting :wink:

https://www.robotshop.com/letsmakerobots/node/2023

or perhaps "drive 200 forward, pen down" / "drive round 176, pen up"…

Nice video - imagine that, showing your face, talking and all :smiley:

Wow!

Very cool! Learning by example. That’s the way to go.

I like the board too.

Look at his little Face!

If I ever saw someone proud of their work, that’s you!!

AND RIGHTLY SO! I remember the I2C conquest. It’s a treacherous, nightmarish path to the top, but once you’re there, it’s soooooooo worth it!

Now, on to those Knight Rider scanning lights, then what other patterns can you program?

I feel it won’t be long before you’re mapping a room, or using the ADC to sample audio…

Let’s make one!

 

It doesn’t look like a desperately complicated board. Do you suppose we could make a similar one?

I don’t know picaxe, but I know lots about the raw PIC. I’m pretty sure with a little thought we could produce a generic pic/picaxe PCB and make the schematics / track layouts available freely. Perhaps even sell pre-etched boards to help pay for a new server?

 

My mind is exploding!!

First of all

BOA -Audio sampling… Damn that’s good! Any you are right, it is sooo awesome when you finally figure out a puzzle.

As for now, I am thinking the next step would be a recreation of those old programmable cars from the 80’s. Remember these? -You know, 8 arrow keys and you could program a little routine (2 units fwd, 1 unit turn right, 1 unit rev.) etc.

I love the suggestion of bio-feedback! Should be simple enough to make a splint-like thing for my arm and add some pots. Sparkfun sells these which seem pretty cool to make a virtual reality glove out of. --So many ideas!

And in terms of the board… It comes from R4 Systems but you can only get it here. Yup, its our old friends that take your money and don’t send your stuff. Even more unfortunate is that their deal on this board it great! You get all 4 picaxe chips plus the board at a great price. The board has space for any picaxe chip, a darlington, motordriver, and an 8-pin EEPROM also on board is a 5v reg, spkr, 4 buttons, 2 trimmer pots,8 leds, a 14 pin output for LCD. My only complant is that it’s output pins are all singles… None are 3-pin with the V and G next to the output. I have spoken to R4 systems and they say they can get one to me directly, but I think it was just to me (no a public offer). I would love to see a similar board made and sold here -Maybe we can all vote on features and then produce it! I would sure buy a couple!

Once again, I can’t say enough how much I appreciate everyone’s help. When I first got here I was still making an LED blink. Every step of my robot education has found kind assistance here. Thanks to all and thanks to Frits for this great site!

 

Woo Hoo!!!

Their deals are great. I
Their deals are great. I don’t get why everyone complains about them, though. They managed to get my stuff to me on time; I guess some people are just unlucky when it comes to PICAXE distributors.

fabulous man, this plaque
fabulous man, this plaque Electronics is great, you can make many interesting projects, thank you for showing us your new acquisition.

greetings from Guatemala

I can’t believe you blamed
I can’t believe you blamed your fart on your wife’s arm… Good project I want to tinker with this eventually.

I want beer! I’m kidding!

I want beer! I’m kidding! jejeje
Excellent second test, it works wonderfully, even the idea of using infrared to save the trajectory of the robot is a good idea, I hope to see very soon the testing number three. besides you’ve given me good ideas, Thank you.

Regular Samples

I think we’re starting to get a psychological profile, now. Obama, surf boards, steel drums… Do you ever get to spend time with your WIFE?

I’m curious: in your second robot, why would you want pot attached to your elbow? Oh, wait. I get it. :slight_smile:

I was wondering: are you sampling the pot at regular intervals or only if there’s a substantial change? You could save yourself a lot of EEPROM byonly sampling when there’s a (predefined) minimum change, then prefixing the sample with a timestamp, so you know when to replay it. In the case of the rotary position sensor, would you consider, counting the number of holes passing the sensor, then writing that number to the EEPROM when it STOPs rotating for a certain amount of time? That way, only one number is written to EEPROM per “move”.

Other point: Did you know you can hook 8 EEPROMs in parallel? Assuming the one your usingis a 24xxyyy series, they are 3-bit addressable. Yours may be hardwired to address 0, (although, 0 is the default address is the address lines aren’t wired) but I’m sure a man of your calibre woudn’t have any bothermaking a little daughterboard to plug in in place of the existing EEPROM. I’ve got one with 8x 1024kBit chips on. I can play 8-bit 11kHz audio samples from a PIC through a resistor ladder DAC!!I get about 12 seconds.

PS - do you work for this beer company, or do you make it yourself?

data compression at the source

I was thinking the same thing as soon as I saw your first test. OH, I love the way you are sharing your projects with us by the way! As it is, you are recording a fixed number of samples per second. Your limited amount of memory (whatever the setup) will be filled with mostly redundant data. Depending on the ratio of (samples/change), you could really save a lot of memspace! BoA is suggesting to compress the input data it at the source. Only recording changes in recorded input. A good suggestion I think.

He also explains that playing back moves (compressed input changes) would present you with a considerable speedup in playback unless you also record when to play back each move. But that presents a new challenge. “What is considered a good timestamp for your kind of data?” Absolute or relative. Relative to the last data point, or to other recorded events?

Those encoders on your wheels, are they coding for distance (s) or for speed (v)? If it is distance, than I would suggest you do not record based on time (t), but on distance instead! Look at your wheels/encoders as your internal clock. (No Rik, that won’t work either, because the wheels are not turning all the time, remember).

Oh boy, I just made this a nightmare of complexity again, didn’t I? Keep on carpenting robots Chris! Ask me again when you’re ready for some more confuscation! 8-/

Recording Time…

Hey guys,

So much to go through… (mostly to BOA and Rik) You guys are absolutly right. I am just using a for b1 = 0 to 255 / next b1 to cycle through while “recording” and writing to the EEPROM at every step. Playback is run the same way. I have found that when I am learning something new, I try to keep the code as simple as possible, using commands I know by heart, before I start to add and evolve. Using this for/next code only gives me about 8 seconds of recording time. I have also played with some pause commands at each step -I am trading “resolution” for extra time. When I get around to using this new found EEPROM knowledge in a real, pratical way I don’t think the simple for/next code will be of much use.

What I have now:

I have started coding my IR remote control idea. The IR commands are the same as this little guy. Using a TV remote, I am using the number keys for directions. #2=Fwd, #4=Left, #6=right, and #8=Rev I am also using #5 for a write to i2c command. The process should be: Each time you hit a direction command it is noted as a “unit” i.e. 2,2,2,5 would be 3 units forward and then #5 tells it to record 3 units/ fwd to the EEPROM. You could then carry on with the next command.

Upon Playback, each data address is read one by one and sent to the “go” portion of the code. If 3 units of fwd are specified coming out of the data log, the picaxe simply multiplies 3 by the number of holes (on the encoder) I have decided a “unit” should be. This whole thing should work just like the old Big Trax except only by remote control. So far, my basic idea is solid and most of the code is working, I just have some bugs to work out.

Onward and Upward…

Yes, my life and hobbies are quite extensive… However, I am blessed with the fact that not only is my wife and my kids understanding but most of the time they participate! My wife Kari and I are both Obama supporters and activists. When I am surfing, Kari and the kids play on the beach. When I am coding my 6-year-old Phoenix is either on the Mac next to me doing puzzle games or in my shop making lights and buzzers go -he already can explain series and parallel and tell you the diference between amps and volts! Not to mention, in addition to being an Herbalist and Massage therapist, Kari builds websites -So even if I am coding all night, she is usally next to me doing the same. AND if that weren’t enough, we are also podcasters and love to find time to record together. I guess what I am saying is, sure I got bunches of hobbies but my family kicks such major ass that almost all of our individual hobbies merge into eachother’s and we get to play together all the time! --How’s that for a psychological profile? :slight_smile:

As for the beer… I am just very stoked to be able to live on Cape Cod (seriously, do a map search for Cape Cod, Mass. it is really a cool little chunk of land) and C.C. Beer is our only local brewery. --Gotta support the locals! --Actually, it was just sitting on my desk, thought I would make a joke about it.

Did I cover everyone’s comments?

 

I think you are wasting

I think you are wasting space :slight_smile:

As I read your code, you are doing “Bitmap”, when you could be doing “Vectors”, explanation (not scientific, but to try to explain):

  • A line of 100 pixels drawn on a bitmap picture would take 100 bits.
  • Drawn as vectors, it would take the info “start point - draw line - end point”

If you are programming it like this:

For variable = 0 to eeprom’s end
Read input -> put that into eeprom
next variable

- you will be filling up your space with lots of nothing’s, no changes; Even if there is no (new) data t record, you will still be sampling, filling up the memory.

However, if you do it like this:

readadc, b0
do:
readadc, b1
gosub pauseroutine
w3 = w3 +1 ’ this is the “timer” (how long before next change)
if b1 <> b0 then ’ only store data when there is change in data
b0 = b1
b2 = b2 +1
write data to eeprom at address value of b2: b1(the value), w3(how long time before this value occurs)
w3 = 0
end if
loop while b2 < eeprom max register

pauseroutine:
do the rest of the program, what ever is needed to be done, and if nothing, make perhaps a straight “pause 25”. The time it takes to do this should be the same when you play back afterwards, and by entering a “pause” command, you can ajust, and perhaps only make it “pause 19” when playing back, to get the same speed, if the rest of your program takes longer to execute when playng back. You can also use the “timer” functions / interrupt…
return

(This code is pseudo very much, however, 100% of the structure and perhaps 75% of the actual code is useable)

 

- Then you will have a double set of variables in your eeprom; Where did the change occour (w3), and what value did it have (b1). When playing back you can then make it like this

 

b2 = 0
Mainplay:
read “w3” from eeprom
read “b1” from eeprom
do:
gosub pauseroutine
w4 = w4 +1
loop while w4 <= w3
b2 = b2 +1
do what you have to do with the data from b1 (now is the time)
w4 = 0
as long as b2 <
eeprom max register, goto mainplay

pauseroutine:
do the rest of the program, what ever is needed to be done, and if nothing, make perhaps a straight “pause 25”. The time it takes to do this should be the same when you play back afterwards, and by entering a “pause” command, you can ajust, and perhaps only make it “pause 19” when playing back, to get the same speed, if the rest of your program takes longer to execute when playng back. You can also use the “timer” functions / interrupt…
return

 

This way you will be able to only store the canges, and play them back at the same speed :slight_smile: