Let's Make Robots!

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

Just a test
AttachmentSize
EEPROM_Test_One.bas950 bytes

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! 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Couldn't have done it without you, Fritsy!

 

Absolutely wonderful, Chris,

Thanks for sharing your learning experiences with us.   I've got ideas on using this concept as part of an auto-navigation project, but I've got a lot of thinking about it to do...

Duane S

Wilson, North Carolina  USA

Wow Chris!! Test 3, WOW!

i still remember when you entered the site the first time :) Man, you have made progress over the last 6 months.

Dude, you have some in ya!

 

That is to say: I am trying to subscribe to this node and I think I need to reply in order to do so.

Update: I did it! I managed to click on a link to subscribe to this project. Still best project effar though.

Programming a series of commands in time requires a different data model than a series programmed in events. This is what I mean by that:

The VCR remote provides its own sampling method. It is series of discrete values. The playback of those commands are in the same order as they were recorded, but not necessarily at the same speed as you pressed those RC keys.

The elbow sensor (pot) feeds continuous data into the PIC that must be sampled (at a given time resolution). The programmer/carpenter must decide how to discretize the input. Probably by adjusting the pause length in between samples (the time resolution).

By adding a trigger in the elbow sensor setup, it is the puppeteer (person in the elbow sensor) who controls the resolution. Each time he pulls (chews?) the trigger,the PIC is ordered to read another sample. Thus turning it into an event based series. Expect the playback to be out of sync again (time wise).

Final thought: introduce the null-command (channel zero on the RC perhaps). This gives the puppeteer the opportunity to influence the playback speed. Somewhat.

8-)

 

I understand it fully! AND it is really good code! AND AND you are right, 75% is usable. I have been playing with it and it is going to work well with my "pots on my elbow and wrist controlling a robot arm" project. For now, I am still working on my "Big Tracks" code. --I'm pretty close with just one stupid, stupid bug!!! Soon, my friend.

I think you are wasting space :)

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 :)

I think that was a brilliant reply. So clever that noone understands. Nice.
It's that BASIC stuff. I used to be able to read it.

hear hear!

8-p