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.
Retro this is good work but if one should want to implement the Elvis with this program then all motors must be removed and servos implanted. my attempt is to keep the motor and gearbox attached and use the r/s 232 to spit out highs and lows and read the VRs that are needed to make this work. so of course more hardware is to be made for this action. I will use the program you are making with revisements to it when I get a chance to go back to the Elvinator Project if thats ok with you! We could have both of these options embeded into the code so that what ever the hacker wants to do they my do so with either approach. I'll keep my code modular to keep things simple as this is the best way to do it as least I think so. When I get mine up and running I'll post you the changes so you can say ya or na on the code.
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.
BTW, the Mini-SSC format is just just 3 bytes per command: One sync byte which is always FF, a servo channel byte between 0 and 254, and a position byte which is 0 to 254.
The format is almost too simple, really. But at the moment what my program does is translate the MotorIDs from the animation script to the user-selected servo channels, and then translate the 32 possible positions from the elvis animation into scaled postion values between min and max. For example, I am just dividing 256/32 (8) and then multiplying by the position values that I scaled to 0 to 31. So a position value of 65 originally, becomes 0 and 31 becomes 254 (I manually chop it off at 254.)
The point I am trying to make is that the program doesn't really care if there are servos connected to a Mini-SSC, or if it is talking to "GWJax's controller" which takes the commands and moves DC motors instead. It will just convert the frames to whatever command packet you tell it to and spit it out over the serial port and lets the microcontroller on the other end deal with it.
When you are saying "highs-and-lows" I am not 100% sure what you mean. It sounds like you are saying you are going to spit RS232 bytes at it where the bits in the bytes ( 20 bits for 10 motors) is just raw on/off information for a motor. I really doubt you intend to do it that way, though since you really wouldn't need anything more than a few cascaded shift registers to do that. If you are connecting a microcontroller, I would assume a nice set of formatted packets would be implemented.
You know what they say, to assume makes an ass out of you and me.
It sounds very much like that is what GWJax is planning, except you overlooked the bit about reading the ADC values.
Here is an example of an profile file I am currently planning to implement. Entries might change as needed:
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.
:) These things often come down to personal preference and what is most convenient. For me it would be using a microcontroller, because it would be practically plug and play, I wouldn't even have to breadboard it. Offloading the control functions to the PC would also save me a lot of time during testing and cut code complexity (on the microcontroller). If I was doing it for something other than a one off in my garage, I would of course do it differently.
Out of curiosity does the program currently handle reading the current position of the motor over the serial link?
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
Responds=False 'The controller can return serial data
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
Nocturnal said: Out of curiosity does the program currently handle reading the current position of the motor over the serial link?
Currently, no. But, as you will see in the last post, I am setting up for being able to define controllers that can send information back. With that, you could get motor positions. I haven't gotten that far yet, so I am not sure how it will be implemented.
As far as personal preference, I fully understand that. My only point is that the program can still do it with the right information to implement the conversion. Or GWJax can NOT support my program, either. Doesn't really matter. :) I am personally not planning to control Elvis the same way as him, so I will still find it useful, no matter what. Since I am writing the programs anyway, I thought it would be nice to make it expandable and useful for others and for future projects. If I were doing it only for myself and only for one project, I would just hard-code the conversion in to whatever I planned, and life would be much easier.
If I ever build my own animatronic head with just servo controllers, I could use my programs to animate it instead of purchasing expensive commercial programs.
I am of the school of thought that you work hard to work hard only once. ;)
I am of the school of thought that you work hard to work hard only once. ;)
I use a similar school of thought :) Which is why I still have almost every bit of code I have ever written. Code reuse make life much easier.
OK I'm back, this is what I have plans for the Elvinator Project. YES it will be PC controlled as I have many diffrent programs that need to run at the same time such as voice control, feedback to the user to have a conversation with him and a bit of terminator quarks that will pop in form time to time. the movements are just a part of the whole scheme. I can use yor program for some setups on stationary scripts but most of the control will be on the fly under PC software control. There is one part of you main display form that I will change. Rather than clicking on a movement button then display the voice script, I plan on changing the layout from a vertical slide bar to a horzontinal slide bar with the graphic script under it so you can see the whole visual script at once rather tha one at a time. Just a personal preferance.
I think this program will give me the upperhand on my controller, So yes both a MCU and the PC will interact with each other. As the controller is still in its designing stage I will make modifactions to it as needed to keep both PC controlled and standby random mode with/out PC control an option. This is going to be a very hard task for me to get it right but I want to make sure that both of our programs can be used togeather.
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.
Yes that does make alot more sense, having the computer using scripts and sendinging them to a MCU an let that control the actions would cut down on alot of programming. The more I think of it the better it sounds. Onced finnished with my program I'll upload it to you in source code and the forms in an EXE file.Although this will be awhile because I have alot to finnish up right now before tackling this as Mech Wars are comming soon and I need all Free time to complete the Mech so 4mem8 can make the covering for it.
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?
Just a little Joystick testing mini-app to cut my teeth on some of the features I am going to need to know how to do to implement joystick control in the animator program. Also, some of the graphics code for reticule displays will be useful for the motion capture feature.
Retro I had misplaced my joystick for the computer, so I will get one today and check out the code you sent. Also I like the new look you have done with the main display. I can see this working great with the Elvis in getting it to move just the way you want. Is there a way that you can convert your card to plug into the computer and have it rewrite routines while it's on? This would greatly improve the joystick as a teaching joystick app and make it easier to see the custom anamations live.. Just a thought If not then have a picture of diffrent locations of the elvis head that moves when you move the joystick and play back the anamation via picture frame as a sprite [Old term] new term anamated gif. This would improve in all the function of the program and the ease of use for the beginner.
Jax, I haven't figured out exactly how the firmware is accessing the cartridge yet, so I am not sure how possible that would be. It would probably be possible to write custom firmware that could do this, but then, I am focusing on adding a serial port instead.
I had contemplated the sprite animation, blitting graphics pieces on top of a generic picture, using vector art (you can see that in the pictures at near the top of this thread) but I think I am going to try to do a very low polygon 3D animation for the simulator. If I get that working, I plan to eventually completely replace the slider interface with it. In other words, you drag the head and the features however you want for each frame. Joystick control would obviously work best if it is recorded in real-time. So, we'll see. Right now, all that stuff is beyond my capabilities, but already much of the stuff I have been doing lately was beyond my capabilities not too long ago.
OK got ya. It is amazing what we can do when you put your mind to it.. But having a clear head as well helps out alot.
Nice, this is getting to be pretty impressive!
Hello! I would just love to be a tester for this program, no matter the stage. The reason I got Elvis was specifically to mod and reprogram him, and using an existing program to create new codes for movement would make things much easier than trying to figure out on my own!
My skills are quite limited, but I'd love to do something to help out this project!
kudaranai, I do have the source code that retro had provided me and had done a few upgrades but I can not share it with you. Retro which has been out of the community for some time is the only one that can give you this information unless he allows me to send it to you. Thanks for your interest and I hope he will contact me to let me know if I can share it out with others.
You are free to do that, GWJax. Hopefully some day I will be able to return to all this. I just got married and gained three children as a result, so my life is pretty busy right now.
Congrats, retro! The hacker world just expanded.
Retro!!!! Congrats on the instant family.. That explains what happen to you for many months. I'll make sure that I get the source code to Kudar later tonight.. welcome back brother..
I thought I'd replied on this thread before, but it appears I must have sent a direct msg. I'd love to try this out as well.
Jax, would you be so kind?
Retro - congrats!
No problem. Let me make a zip file of retro's files that he will allow me to share with you all. the file is large so I will send you a link from fileshare that will last only for 10 days. So when you get the PM please download it with in the 10 day period.
Now the other changes I have made to his files are not in this zipped folder. when I am finished with my version I will post it in it's entirety but this will be a while because I'm using it for the Elvinator Project of mine.