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

[JonnyMac]

See the program I attached above -- it works.  What we both did, I'm guessing, is connect the servos to P0-P2 and those pins had not been made outputs (that's now fixed).  I also found an error in the code that reads the servo data which was causing the servo 1 position value to be overwritten by the servo 3 value.

[davisgraveyard]

Jon, you are freak'n AWSOME!   It works!!!!!!

I like the multiplier on the read.  That way the data stays the same.  IT works GREAT.  I'll have to take a video and show you how it all works!   I think I have something I can work with. 

I will still try to work with the Prop-SX and see if I can program the data into the EPROM. It would be nice to have a little bit more detail for the head movements.

again, THANKS!

Jeff

[JonnyMac]

I rule!   ;D  Now go watch and vote for "Strangers" (see Misc. forum).

[davisgraveyard]

Cool video!  Chris and I both watched it.  Voted thumbs up and sent to fellow haunters.

I spoke too soon about my program.  The servos are working great and the data read is fine.  It is just a timing issue with the show.  My show is ending before the audio and then starting again before it has finished. 

One of the issues is program structure.  I have attached it so you can take a look.    I need to add a couple more LED fades at the beginning and ending for spotlights before the eyes but thats not the problem.
I also think my repeat count isn't correct for the data.    The repeat counter isn't high enough so it ends too soon.  I totaled up the orginal files repeats and they came to 6225 when I added up the ones in the DATA statements they are 3663.  I will check my program that munges the data to see how I am loosing them.

Any pointers would be appreciated....again thanks for all the help.

Jeff

[davisgraveyard]

I fixed my problem with my data munging routine and now can create 400+ DATA statements with the proper number of repeats.

Made a few changes to the code.  Still having issue with the show ending before the audio is done.  The MP3 length is 0:01:54.

I have 424 DATA statements with a total of 6257 repeats.   I bumped the Refresh_Servos routine PAUSE to 20.   That would make 125.14 seconds but the show finishes reading all the data before the MP3 finishes?  What am I missing?

Jeff

[JonnyMac]

Herein lies the problem with the BS2 in this kind of application.  While easier to program it is less precise than the Prop-SX (this is not a knock, just the way things work).  Here's what I mean:  Let's say that you collect servo data every 20 milliseconds.  Great, no problem.  With the Prop-SX we can create a background process that loads new servo values every 20 milliseconds -- right on the dot. We can't do that with the BS2.  Why?  Because we can only run a single thread.  What we're forced to do is take a compromise position on loop timing.  In your case you have three servos use a total of 3 to 6 milliseconds depending on their positions.  So what value do you use to pad the loop for 20 milliseconds?  I would start with 15 since the average time consumed by the servo pulses should be on the order of 4.5 milliseconds and you have other overhead.  My point is that you're going to have to experiment with your loop padding to so that your show data more closely matches the track that you used to record the moves.

[Edit] I had a look at your program.  If possible, crank up the baud rate to/from the uMP3 to 38.4K as this will minimize TX/RX delays.  Also, remove the RETURN from Get_Record so that it drops through to Refresh_Servos; this will help, especially in the beginning where yo have a long fade-up with no refreshing of the servos.

[JonnyMac]

Looking over your program and keeping the previous thoughts in mind I came up with this idea:

Refresh_Servos:
  PULSOUT Servo1, pos1 * 5
  PULSOUT Servo2, pos2 * 5
  PULSOUT Servo3, pos3 * 5

  dPad = (pos1 + pos2 + pos3 + 50) / 100
  PAUSE 20 - dPad

  RETURN

The idea here is to calculate -- to the nearest millisecond -- the amount of time used by the servo pulses.  Perhaps this will get the loop timing closer and help it keep sync.

Also, I would remove the status check of the uMP3 that's in the middle of the play loop; once you've got sync you really shouldn't need that.

[davisgraveyard]

I implemented all your suggestions but still was coming up short on the show.  So I incremented the PAUSE value in the Refresh_Servos until it worked.  I ended up making it PAUSE 40 - dPad before it worked.

THe problem with such delays is the head movements are pretty choppy.  So I set it back to PAUSE 20-dPad and added a PAUSE 15 in the repeats loop.  To slow down the refresh between each repeat.  Basically did the same thing.  Still choppy.   

I had an idea.  It might take a bit of coding but I wonder if we can smooth out the movement and extend the timing by calculating the difference between one read and another 

so if I read

DATA 164, 161,162,20
I store pos1-3 values to oldpos1-3 values
then read
DATA 172,161,162,13
and instead of just jumping to the new value I increment/decrement  the pos1-3 one at a time and refresh within the number of repeats.  SHould make the movement less choppy and will add some more time to the show?

What do you think?

[JonnyMac]

I'm torn... it seems like you're now trying to code around the massaging of the original data.  I've updated your program and even tried to improve the loop timing by replacing the big PAUSE in the servo section with a PULSOUT which is much more precise (luckily, you have spare pins). 

This version will take the new servo value and the last and average them, so you will have to tweak the loop timing and you may need to tweak the repeats column as well.

[davisgraveyard]

Not really code around the orginal data massage as much as correct a side effect of stretching out the timing.  If we play the data with little or no delay then it is almost as smooth as the orginal data.  But with the delay to stretch it out to fit the show it is very choppy.  But I did notice on the first few passes that the massaged data (in order to get it to fit on the Prop-2) was a bit sloppier than the orginal VEX movements.  But I figured I could live with it even if it was a bit "robotic".

My new coding idea was more of a way to go back to the orginal data without having to store it all as DATA statements.  The massaging I did is really just removing all the single PULSOUT changes over time so what I ended up with is the major position changes with large repeat values.  So the servo jumps to a new position and waits there.  If we did separate PULSOUT's incrementally between those changes it would probably be smoother and take a bit longer to get there?  This would get rid of the effect we are seeing right now which is robotic.  and the introduced delay makes it choppy on top of it. 

I will try your new code and see what kind of difference it makes.

Thanks for all the help.

Jeff

[davisgraveyard]

Wow!  That did NOT work!  Threw the head around and then crashed.   I didn't edit the program just loaded it as is.

[HauntedWolf]

So did anyone find a way to import the VEX built movements into VSA?

[davisgraveyard]

Funny you should ask.  I was just thinking tonight about another approach to my whole Prop-2 and Prop-SX DATA storage issue.   I've been trying to do this talking skull without tying it to a PC but I'm not happy with the tradeoff off less data points which translates to less smooth movements.  I REALLY liked the way the head looked when moved with the VEX transmitter. But that created over 3000 data points.   So now I'm thinking what if I put that in VSA or Vixen and just played it back?  If I'm going to bite the bullet and go with a PC then I can also drop the uMP3 and just play the audio with the PC.   Now the prop controller is just a dedicated servo controller driven by the show software.   

So now I too would like to know how I can import my data into either VSA or Vixen.  And what would the connection be from the PC to the Prop controler  and should I use a Prop-SX or a Prop-2?

Jeff

[HauntedWolf]

I'm using an SX...so I'd be interested in that.

[JonnyMac]

VSA has an import option but I've not used it.  I'm assuming (that's dangerous) that since it exports CSV it may want to import it that way has well.  Here's the danger for you, though: you recorded data at 20ms and VSA's fastest frame rate is 33ms....  Still, it might be worth a try.