Vex Transmitter to Prop-SX to Servos + PC (via Serial)

[davisgraveyard]

Funny you should post this right after I just came to the realization that this isn't going to work on a Prop-2.   I was able to cram about 395 of the 1097 data lines.  That 1097 was compressed down from the 3000 lines where only 1 servo changed 1 value.    You are right  No-way-no-how.

I only thought about using the Prop-2 since I was going to use an external board for moving the jaw which generated most of the data to begin with. But even gently moving the head creates too much data for the Prop-2.   

I grabbed the same program you just posted to try it but can't get the data into the 2k EPROM.  So I am back to using the Prop-SX which isn't that big of a deal but I have to keep flashing the program to go from recording to playing.    I'll let you know how it goes.

Jeff

[JonnyMac]

You realize you can't "flash" data into the external EEPROM of the SX, right?  Now, if you've written a program that copies DATA statements to the EEPROM, you're cool.

[Edit] I take it back, a program to move DATA statements to the EE is pretty useless as there is only 2K of program and data space in the SX.  The idea that I'm pondering, but haven't fully fleshed out, is using a program that allows the PC to send data serially to the SX -- this would be the best way to fill the entire EEPROM.

[davisgraveyard]

As usual my choice of words fail me.   I have 2 programs.  One is AnimateSkull.SXB with all my data statements in it which is 77K and the VEX_Servos_EZ.SXB which has the code to capture the VEX controller and send the data out serially.    So I guess what I meant was I have to "re-program" the SX not flash it when I want to switch between capturing movements and testing the data.

Right now it looks like my data is still too big even for the SX.  Won't compile.  I have about 2957 data statements of only 3 servos. 

Which brings me to my next issue.  I only have 3 values in my DATA statement but the code is written to move 4 servos.   I have servos plugged into Pins 0,2,3   I pulled the servo from pin 1 because it is the jaw.  So the code can move the pin if it wants but there is no servo.  But it can only read 3 data elements so in the movement code I am doing

READINC pos0, pos2, pos3, timing

will this work or do I need to do something else to use only the 3 data elements with my servos?

Jeff

[davisgraveyard]

Just compressed down the DATA lines to 1097 by removing any entries with a timing of 1.    But the program still won't compile.

The program code is 41k now.

[JonnyMac]

It is often difficult to see things in isolation -- can you attach the whole program so I can have a look.  Remember, too, that the SX has only 2K words of flash; your data statements are going way past that.  I really think the key is going to be writing a program that receives the data serially and stuffs it into the EEPROM.

[davisgraveyard]

I'm confused.  I thought that one of the big reasons for going with a Prop-SX for an animated head project was that the memory size for the program was MUCH larger than the Prop-2?   If I have the same space limiatations on the SX that I do on the Prop-2 then why bother?  I should try to condense down my movements into something that would fit on the Prop-2?   If we can figure out how to get the the extra data statements onto the EPROM through the serial port that would be nice but I am slowly running out of time.  This project has to be up and running in a month.

I realized what the real problem here is.  Using the VEX capture program generates a LOT more data points than you would have if you were manually putting movements in Vixen or doing it in code.  You'd might have 100-200 data statements for head turns,nods,tilts in a 2min show.   But because we can use the VEX to capture movements in realtime the changes are much smoother and if played back would be more realistic.  But it is more like 3000 data statements for 2min show.  Even if I compress the changes down we are looking at 1100 data statements at least.  Maybe I could create a threshold for the timing value when building the data and say that I only keep data statements with a time value of 5 or greater?  That would reduce the statements quite a bit?

Here is the SXB code
www.davisgraveyard.com/AnimatedSkull.SXB

[JonnyMac]

We have never claimed that the Prop-SX had more program memory, because it doesn't.  That said, it does have a huge EEPROM (relative to the Prop-2) that is available for use that is completely separate of the program memory.  The reason for using the Prop-SX is horsepower; the ability to do serial communications and servo stuff at the same time (e.g., with Vixen or VSA).

A project that I have on my list is a utility to download data from a PC into the SX EEPROM through the serial connection.  The Prop-SX end is easy, I haven't sorted out the PC end.  The easiest thing to do, I suppose, is create a program that simply dumps 32K of data into the SX.  The SX has to control data flow because burning the EEPROM takes a few milliseconds per write, and the block size is just 16 bytes (I believe).  At 10ms per block the full download would take about 21 seconds.  Perhaps this is a project we can work on together as you do more PC programming than me.

I use a piece of video editing software called Vegas that has a neat feature.  It lets you record volume or other analog changes in real time and then goes through and smoothes these data points with interpolation.  By removing noise and small (non-deliberate) moves from the input the data points are reduced.

I don't know if it would have ill affect on your moves, but you could do a simple averaging on your data.  Take five data points, average each channel, then use the average values for five cycles.  It's simplistic, and may not give you the results you want -- but as with any experiment it will be educational.

[davisgraveyard]

I agree the horsepower of the SX is usefull for simultanious servo and comm stuff.   But as I have already offloaded the jaw movement to a dedicated board and most of the show is sequencial the Prop-2 works.   Now if we can get 32K of  data statements burned into the EPROM THAT would be something.  I'm surprised there isn't a way to do that now either in the SX/B IDE or a stand alone utility.   I would be glad to help write a PC program to do it if you want my help.

I have modified my DATA statement creator to skip the fine detail movements and only keep ones based on a threshhold.  It works to get the data down to a reasonable size but I haven't been able to test it yet.

For the time being I have moved back to the Prop-2.  I have been munging the data statements and can get it down from 3000 to about 495 and it fits into the Prop-2.    I did notice that the same process does NOT fit into the Prop-SX.  The Prop-SX program is larger so there is less room for the Data Statements  and even at 300 statements I couldn't get it to compile.

So I'd like to ask the question again for the 3rd time.  What calculation do I need to change my 100-200 range values from the VEX program to be used in a Prop-2?   Is it just a factor of 5 like going from a Prop-1 to a Prop-2?

Jeff

[davisgraveyard]

I have converted my DATA statements to values that are a factor of 5 from the VEX values.   But my Prop-2 program doesn't move the servos the same as they were in the VEX?  It seems like those values are forcing the servos to far to the extream?  For example.

These are the VEX values
DATA 172,161,162,15
DATA 177,161,162,7
DATA 182,161,162,6
DATA 184,161,162,6
DATA 187,161,162,6
DATA 188,161,162,10
DATA 190,161,162,26
DATA 190,161,162,15
DATA 189,161,162,9
DATA 155,162,162,6
DATA 130,162,162,6
DATA 124,162,162,9
DATA 122,162,162,6
DATA 124,162,162,31

These are * 5 for the Prop-2

DATA 860,805,810,15
DATA 885,805,810,7
DATA 910,805,810,6
DATA 920,805,810,6
DATA 935,805,810,6
DATA 940,805,810,10
DATA 950,805,810,26
DATA 950,805,810,15
DATA 945,805,810,9
DATA 775,810,810,6
DATA 650,810,810,6
DATA 620,810,810,9
DATA 610,810,810,6
DATA 620,810,810,31

But the movements aren't the same?

[JonnyMac]

I wasn't clear.  You could take five lines an average each column.  Then drop column four and replace that with 5 for the five cycles that these values will hold.  Hence:

DATA 172,161,162,15
DATA 177,161,162,7
DATA 182,161,162,6
DATA 184,161,162,6
DATA 187,161,162,6

... becomes:

DATA 180, 161, 162, 5

This s a simple form of digital filtering.

[JonnyMac]

If you decide to go back to the Prop-SX you can use the attached program do download 1K data chunks.  Simply change the DATA table (256 rows of four bytes) and the EE_BLOCK (0 to 31, each block is 1024 bytes) number.  The starting address for the data is calculated from EE_BLOCK.  An LED flashes rapidly while downloading and if all goes well it will extinguish.  If an error is detected (each byte is read back after written) then an second LED flashes to let you know there was an issue.

[davisgraveyard]

The short example I gave was already filtered down from the one below.  I could try your approach but I just filtered out the time values less than 6 and added them to the next value until it became at least 6.  I was trying to keep the time the same with less entries so the show took the same amount of time with less data entries.  If I average the values then the time values will be shorter and then the movements will be done before the speech right?

DATA 172,161,162,15
DATA 173,161,162,2
DATA 174,161,162,1
DATA 175,161,162,3
DATA 176,161,162,1
DATA 177,161,162,4
DATA 178,161,162,2
DATA 179,161,162,2
DATA 180,161,162,1
DATA 181,161,162,3
DATA 182,161,162,2
DATA 183,161,162,5
DATA 184,161,162,2
DATA 185,161,162,4
DATA 186,161,162,2
DATA 187,161,162,2
DATA 188,161,162,10
DATA 189,161,162,1
DATA 189,162,162,1
DATA 189,161,162,2
DATA 190,161,162,25
DATA 190,162,162,1
DATA 190,161,162,15
DATA 190,162,162,1
DATA 190,161,162,3
DATA 189,161,162,3
DATA 189,162,162,1
DATA 189,161,162,5
DATA 188,162,162,1
DATA 187,161,162,1
DATA 186,161,162,1
DATA 185,161,162,1
DATA 184,161,162,1
DATA 183,162,162,1
DATA 181,162,162,1
DATA 180,162,162,1
DATA 179,162,162,1
DATA 178,162,162,2
DATA 177,161,162,1
DATA 176,162,162,1
DATA 175,161,162,1
DATA 173,162,162,1
DATA 172,162,162,1
DATA 170,162,162,1
DATA 169,162,162,1
DATA 167,162,162,1
DATA 166,161,162,1
DATA 165,162,162,1
DATA 164,162,162,3
DATA 164,161,162,1
DATA 163,162,162,1
DATA 163,161,162,2
DATA 162,162,162,1
DATA 161,162,162,1
DATA 160,162,162,1
DATA 159,162,162,1
DATA 157,162,162,1
DATA 155,162,162,2
DATA 154,162,162,1
DATA 152,162,162,1
DATA 150,162,162,1
DATA 149,162,162,1
DATA 148,162,162,1
DATA 147,162,162,1
DATA 146,162,162,1
DATA 145,161,162,1
DATA 144,162,162,1
DATA 142,161,162,1
DATA 141,162,162,2
DATA 140,161,162,1
DATA 140,162,162,1
DATA 139,161,162,1
DATA 138,162,162,1
DATA 137,162,162,1
DATA 136,162,162,2
DATA 135,162,162,2
DATA 134,162,162,1
DATA 134,161,162,1
DATA 134,162,162,1
DATA 133,161,162,1
DATA 133,162,162,2
DATA 132,162,162,1
DATA 131,162,162,1
DATA 130,162,162,1
DATA 130,161,162,1
DATA 130,162,162,2
DATA 129,162,162,1
DATA 128,162,162,1
DATA 127,162,162,2
DATA 127,161,162,1
DATA 126,162,162,2
DATA 125,161,162,1
DATA 125,162,162,3
DATA 124,162,162,5
DATA 123,162,162,1
DATA 122,162,162,6
DATA 123,162,162,1
DATA 122,162,162,1
DATA 123,162,162,3
DATA 124,162,162,29

[davisgraveyard]

Still not sure why my Prop-2 PULSOUT values from my DATA statements are not working?   Is there more to it than just multiplying the VEX values by 5?

Jeff

[JonnyMac]

If you setup your run-time engine such that the last entry in the record is the number of repeats, then no, you will not have your data finish ahead of your audio. 

I frequently convert BS1 programs to the BS2 by multiplying the BS1 PULSOUT value by 5; works all the time.

[Edit] I added your servo values to my 3x Servo engine and did some tweaking (as well as fixing a typo that was overwriting the servo 1 position data).  I changed some pin assignments so please check the definitions sections.  It works.

[davisgraveyard]

So the Prop-SX VEX program from this tread outputs the same values as a Prop-1?   But when I multipy the values by 5 and do PULSOUT the servos are not moving the same way?

As for the timing issue I don't think you understood.    You suggested doing an average sampling to reduce the data but if I reduce the DATA statements I need to keep the repeat count the same so show timing stays the same.  So I can average the PULSOUT values but need to sum the repeat values.   My issue is that the orginal captured data has a LOT of repeat values of 1 or 2 because of the granular nature of the data.   I have almost 3000 statements to begin with.  60% probably have repeat values of 1.  The guts of the real changes are about 400 statements.   But I have to maintain the repeat count of the orginal 3000 statements so the show time stays the same right?

jeff