@WBS00001 is still at it! He was asking me some days ago if I wanted to check his progress on the script, but as my coding is so limited I told him that I might rather wait a little and get my hands on the finished piece of software since there will be further revisions! The problem persists in that ARC runs on Windows and there is no real timer to precisely drive those servos... @WBS00001 took a swing at using ticks rather than the sleep() command, which means the timing might not be exactly the same on every PC, because depending on the tasks running and the hardware differences of each machine there is a tolerance on how fast the individual PC is able to process those tasks! But this also means that the integrity of the motion will be given and you could think of it like maybe fine tuning your old vinyl record player I guess...

Ease in or easy out motion seems to be tricky...but he already told me that it is more than possible to get this correctly time too!

The last option would be to transfer the data string of the animation to some breakout board which runs its independent timer script and will be able to process this data correctly! This would be the last option because we are trying to stay within the ARCs given mechanics so everyone in the community can use it without the need to purchase extra hardware!

Thanks for showing us you are still interested, @WBS00001 is still rocking it!

@fxrtst EDIT: I see Mickey666Maus has posted while I was typing up my reply. That's fine. He has encapsulated well what I am saying below in more technical detail. So ...

The short answer is ... well, there is no short answer. Would that getting smoother operation was the main problem. Things have progressed beyond that relatively simple goal however. I was getting pretty good results when working with just 3 servos in my initial testing, smooth motion and all. However, scaling things up to 10 is not working out so well. I shudder to think how it will be with 24.

My whole system revolves around running each servo in their own script, thus their own thread. The movements of the servos are tied together by sending out "ticks" from a master timer (counter), also running in it's own thread. Each servo script sets itself up to wait for a certain tick, then, when it comes, do a series of small moves based on frame by frame information from a file generated by the 3ds script. Each frame data being timed to run from subsequent ticks. All that is set up ahead of time such that it all resides in memory (actually in an array).

I had theorized that each servo script working on it's own thread would mean each gets a uniform slice of time to work, thereby helping to make up for the lack of a real-time series of ticks. But that's not quite working at the moment.

So the problem has moved from smoothing things out to just getting the servos to follow the movements as generated by the 3ds script program. And that has gotten more complicated since I had to add data for each frame for each servo in order to have any hope of the playback system mimicking the motions in the 3ds model at all. That is, with regards to speed and direction of motion as the servos goes from point A to point B to point C, etc. All this to achieve the non-linear motion the model shows as the virtual servos make their movements. IF I can get that going, then I can get back to work on smoothing things out.

If I stuck with linear movement as I originally had, things would be fine, but that does not mimic the movements of the 3ds model very well. It gets the servos from point A to point B but bypasses all the nuisances in the movements. Still, in the end that may be all that can be achieved given the real world vs virtual world translations of movements involved. The next level up would be to use a separate controller board and send commands from the EZ-Scripts to it. Not a great solution, but one which holds promise of better servo control since it would have a real-time clock to work with.

Probably much more than you wanted to know. But I wanted to throw all that out there via this post, to see if others have any ideas.

No you can never give too much info! I didn't think you could do the project without an external board. Timing is critical and as you said once you start stacking up servos, the worse it gets. Ease in and out do indeed soften the animation and really is key to a successful set up.

Do you guys have keyframes on every single frame? Or do you have a key frame on say frame 0 then a key frame set for frame 30? I would assume keyframes on every frame would bog down the system. Even if you are looking at just the rotational values not the translate values.

@wb, can you contact me off forum at, [email protected]

Thanks!

@WBS00001 its been quite a while but have you had some luck on this code and getting the kinks worked out?

after reviewing this thread - it seems WBS has done almost everything that was asked. The Max Script that he posted in this thread will export a text file of servo positions. This is exactly what you're all asking for. All that is really needed is a way to import it into ARC

After reviewing FBX - i don't think it's the right direction to go. FBX contains way too much information and doesn't identify the exact positions of each joint - nor is there a way to map it do a servo. I can look into it further, but i believe WBS' script is the way to go.

Let me look into getting Max 3DS to explore more someday in the future

okay, well since it kind of sputtered out and wbs said it didnt work past two servos I figured it was a dead project but alright. on importing that to ARC, will that be a possible plug in? from a text file?

for your work on importing the data to ARC/autoposition controller this should produce a .csv file in the same vein. hope it helps importing with getting that data imported. looking forward to seeing it.

 (
	fn writeData bn toFile =
	(
		data = if bn.parent == undefined then bn.transform.rotation as eulerAngles else (bn.transform*inverse(bn.parent.transform)).rotation as eulerAngles
		format ",%,%,%" data.x data.y data.z to:toFile
	)
	
	fn recursiveWriteData bn toFile =
	(
		format "%" bn.name to:toFile
		format ",%" (if bn.parent != undefined then bn.parent.name else undefined) to:toFile
		for t = animationRange.start to animationRange.end do
		(
			at time t
			(
				writeData bn toFile
			)
		)
		format "\n" to:toFile
		for obj in bn.children do recursiveWriteData obj toFile
	)
	
	fn getFileName =
	(
		return getSaveFileName caption:"Save..." types:"Excel(*.csv)|*.csv|"
	)
	
	fn main =
	(
		root = undefined
		if selection.count != 1 then
		(
			messageBox "Please select just the root joint and re-execute the script." title:"Error: rootJoint"
			return -1
		)
		else
		(
			root = selection[1]
		)
		fileName = getFileName()
		if fileName == undefined do
		(
			messageBox "Please select a filename for the file to be saved." title:"Error: fileName"
			return -1
		)
		file = undefined
		if doesFileExist fileName then file = openFile fileName else file = createFile filename
		recursiveWriteData root file
		
		flush file
		close file
	)
	main()
) 

Ah okay! Now we’re onto something.

I have a real neat idea since you’re familiar with max script and I’m in the dark. What if you exported a csv with your script for me - and I created a plugin?

I think what Will was looking for with fbx is like recreating Max 3D! This goal is to take an export of animation joint movements, convert into servo degrees and import into ARC - not recreate a HUGE existing animation package.

If the problem and suggested solution are both identified and relate to each other, I can create a plugin. The suggestion of fbx would have ezrobot recreating a 3D design animation software and that’s not our forte - also it’s a significant feat since autodesk already has a great software package.

So let’s get a working and dynamic Max Script that exports joint servo degrees as frames and I’ll make a magic import plugin.

Once we get that working - I’d like to explore how we can connect ARC directly to max 3ds and move the robot servos in real-time.