Thanks, Jax. I am trying to finish up some of the frame editing code (like copy, paste, insert, etc...) and then I will point you at the newest source code.

It's a good thing that the video quality is so lousy or it would have given away an easter egg I am planning:)

I think, you, in particular will get a kick out of it when you find it :) I'll have to remember to remove it from the source code before giving you an updated copy. :)

BTW, Jax, I will be adding in some real-time serial output from the editor at some point. It would help to define that ahead of time, so when you make your custom controller, for example, my animator program can communicate with it.

This way, you could use the official animation format and still play them back with your controller. I am assuming that you intend to communicate with your PIC from the serial port of a PC, right? When I modify the firmware to accept serial commands, I will also make it compliant with what we come up with. Then, either way someone wants to build it, they can use the same format and programs.

Well, I've been a little busy. I now have a serial playback application over half-way finished. Thankfully, much of my code is modular now, so I do not have to retype everything all the time. Right now, I "Sort of" have Mini-SSC II serial servo controller compatibility implemented. There are a few things I need to still do to make the code work with different controllers, but at present, it should play back the Elvis animations on the Mini-SSC II (you would need 2 of them). But, I have not fully implemented the min, neutral, and max position translation. This will allow you to define the limits of the individual servos and define a neutral position.

You can step forward and backward through the animation, and for each step, it will spit out the current frame to the servo controller. Playback will automatically send all the frames at a rate of 200ms. It will also playback an MP3 if one is selected.

The program will check for available com ports from 1 to 16, and will choose the first one it finds that can be opened. In the options, you can change the com port. On the main display you have a listbox which will display the current frame output buring playback or stepping. You can also type a string into the box above the list and press send to manually send commands to the controller (might be needed to set up some controllers.) In the options, you can also choose an initialization string which will get sent before the animation begins.

On the options page, for each movement, you can rename the movement, set the address of the controller (when multiple controllers are used), set the channel of the servo associated with the movement, and set min, max, and neutral positions for the servos. I will be adding the ability to load and save all of these settings to a file, so they don't have to be adjusted every time. 

There are so many options to set that I am thinking about just leaving this as a standalone application instead of trying to integrate it into the main program. In fact, I may end up doing that with some of the other features I had planned as well. The main project is already pretty large and not everyone is really going to use all of the features.

Still looking for feedback on what controllers should be implemented. Keep in mind, that in doing it this way, you can pretty much use my program to generate animations for anything. It will obviously just save them as Elvis compatible format. There are some limitations to it, like only 12 movements, and only 32 positions, but when I am much further along, I may even be able to extend that if wanted. If I can make it that far, I really think a general purpose animation program would be very useful to alot of people.

BTW, being able to assign and play back all 12 tracks per frame means that you can implement the two unknown motors into your own animations using your own controller.

Jax, all this program is doing is outputting serial. Right now, it just happens to support Mini-SSC, which means that either a replacement microcontroller (like yours) can accept and process the Mini-SSC format, or a module can be created to support whatever format YOU implement. Since I have no idea what format you are planning to receive your serial packets as, I can implement it for you yet.

But, since all this program does is read the Elvis animation format, convert the frames to whatever format the selected controller uses, and spit it out on the serial port, it can control whatever you want it to. There won't be any need for you to make a private version of the program. When you know how your RS232 commands will work, we will just make a module for it and plug it right in. I am working on putting the controller profiles in INI files, so done right, all we need to do is wrtie an entry describing your format and then the user just has to pick "The Elvinator" as the controller type and that's it; the program will take care of the rest.

At least that is my goal.

Nocturnal, I can't imagine that he meant this on the serial end though. I am certain he is talking about what his microcontroller will be doing. My point to him is that THAT end of it doesn't matter to the program.

Seriously, if you output straight bits to the motors and input ADC data, then there really isn't much need for a microcontroller at all. Just make the PC the main controller.

But, I am sure GWJax will be back to clear it up, so I can stop making an ass of myself. :)

P.S. Regardless, this program can do THAT too, since again, it really doesn't care what you put out on the serial port as long as you describe the conversion.

Well, that looked ugly. Here are just the relevant entries:

[Controller 1]'Entry in drop-down box
Name="Mini-SSC II" 'Friendly name is displayed
 in drop-down box

DeviceID= 'Some of the controllers have a device address
 for more than one controller

Packet_Length=3 ' number of (format) per command packet

Packet_Prefix=255 'Whatever will get sent before each track

Frame_Prefix= 'Whatever will get sent before each frame 

Ini_String= 'Whatever is sent once before the animation begins

Format=Byte 'Data type of the elements in the command
 packet (Byte, Word, String)

Channels=254 'Number of channels that the device is capable of

MaxPos=254 ' Maximum position value that the controller can handle

MinPos=0 ' Minimum position value that the controller can handle

ComPort=10 'Com port and settings for when multiple com ports will be used

Baud_Rate=9600 '

Parity=0 '

Stop_Bit=1 '

Responds=False 'The controller can return serial data

[Servo 2]

Name="Eyes L/R" 'Friendly name for movement

DeviceID= 'Which controller device this movement is located on

Channel=1 'The channel that this movement is on

Min=0 ' The minimum position limit

Max=254 ' Maximum position limit

Neutral=127 'Whatever is the natural position, 
 the jaw would be all the way up for example, 
 here it is middle of the road for the eyes

Jax, I have sent you the source code for the serial animator to play with it and modify it as you see fit. You are right, though, it is only useful for playing back stationary scripts. I think I understand what you meant by "highs and lows" now. For, real-time control, no, this program will not work as is. But, the framework will mostly be there to implement that using the modules.

I still think you should come up with a packet format for communications. There is really no reason that you can't implement that with what you are doing. You could even have your microcontroller echo the packet back with some of the elements modifed, like filled with ADC data. In my opinion, if you just offload all of the motor control to the microcontroller and only use the PC to send simple commands, you will get the most efficient use of your resources and it will be extensible. But, it is entirely up to you how you do it, of course.

Control of the motors is very simple and mundane, and it seems wasteful to make the computer do that work. It will take more resources and more energy to constantly poll the ADCs, build serial packets, send them to the computer, process them on the computer, send a response to the microcontroller, process the data and then output to the motors, than to simply say "Move Eyes y degrees at speed n" and let the microcontroller translate that into actual movement. Then you have more PC resources for the rest of the stuff you are planning to implement.

If you implement a packet format, then you can do either stationary script playback or real-time PC control. It really won't matter whether you are sending pre-recorded data or real-time data, the head will just move how the packets tell it to. That is what I am planning for the custom firmware. Without it, you will have a hell of time playing back the pre-recorded Terminator routines you mentioned.

BTW, once I have the options dialog finished, you will see an idea of what I am talking about. I am planning to put in a "servo helper", which will let you step the servos (or DC motors in your case) in real time, to help the user determine min, max, and neutral positions. They will just move the motor to the position that looks right, and click "Store".

Really, all the automated playback is doing is streaming 12 tracks out to the serial port one at a time at a rate of 200ms per frame. Real-time PC control would be no different, except that you can send abritary tracks instead of a whole frame at a time. For the servo helper, it will just output a single track for the selected motor with an incremented or decremented position value each time you press the arrows. On the bust end, it will just move that motor to that position and stop until the next command packet is received. When you are happy with what that position looks like, you just store the value as the min, max, or neutral position so that the program will know the limits of the movements to use when translating the script for playback.

BTW, is there any demand for this? I need to add a few things like generating images automatically from a picture, making backups, and an editor for the actual commands, but it's all pretty simple stuff to add. I started work on this some time back and put a little effort into it again last night.

What's the interest level for a RoboRemote editor? Should I finish it up in the next few days?