@fxrtst
Thank you for the links. They were most informative.
@Mickey666Maus
What I have seen of the code involved in the links fxrtst provided is that all of them are using the same basic method we are using in the 3ds project. For example, the Blender project simply sends the servo position to the controller card as the virtual servo moves. The difference is that it does not use the network to do it as we do. And that makes a big difference in the smoothness of the operation. However, there are steps that can be taken to smooth out the operations when using the network method as well. Some may be mathematical in fact. But I'll explore them a bit later. For now I'll concentrate on doing better whit what we have, as described below.
Anyway, all that got me to wondering would happen when I use the file generated by the Maxscript directly in ARC. So I whipped up a quick ARC script to read the file and run the servos accordingly.
What I found was that the servos run much smoother (as expected) when the servo commands come directly from a file instead of coming in through the HTTP Server control via the network.
Additionally, I found that the 33.3333 sleep period between frames (groups of servo positions) was too long and causing some of the rough movement. When I changed it down to 10ms, for instance, the movement was smoother.
This, in turn, led me to the realization that we did not need to send the sleep period every time we sent out a servo command. Something I should have realized before, but was too blinded by science to notice it I guess.
So now, I just send a sleep command once at the beginning of the output and that's it at first. Unless and until a change in sleep period occurs, only groups of servo position commands are sent. This allows for faster transmission and can result in smoother operation. Also, the sheer fact the Maxscript program is sending out groups of servo position commands, is a delay in itself. It will be some X-milliseconds before another command for a given servo will be sent again as the other servos are processed and sent. The more servos, the greater the delay. That can have a pronounced impact on the smoothness of of servo operation. However, that can also be used to calculate the appropriate sleep period. The more servo positions being sent, the lower the sleep period. Such a thing can be calculated either at the ARC end or the Maxscript end. For now it will be at the Maxscript end.
The tests so far have been with only 3 servos. There will be much greater delays when 23 servo positions are sent. I'm thinking I will need to introduce software steps that will check each servo for a change in position and not send anything out for servos that have no change in position, as opposed to sending every one out every time regardless. Basically using the delta compression principle of only sending data which has changed from the last time data was sent.
I will enter new code in Post 21 when I get things going on the Maxscipt end, and I'll post the ARC script I am using to test the direct reading of the file method, when I am done with testing.
EDIT: Oh yes, I forgot to mention, I had to save the servo positions in the Movement.txt file in a different format from the proper one for ARC script. Instead of Servo(D1,60) I had to use Servo,D1,60. This is due to an ongoing bug in the script interpreter. Anything in a string should not effect the code. However, a close parenthesis symbol in a string will be interpreted as actual code. If you try to use it like that you get an error saying you're missing a parenthesis. So you can't have one in any string. In this case, that string would come from the Movement.txt file and the reason for the change in format. It is read Okay, but as soon as some instruction tries to act on it you get the error. Since I had to change the close paren to something else, I decided to use a comma because there already was a comma in the statement and I was using that comma in the Split function to grab the data out of the string. To make it simpler still I also changed the open paren to a comma.
I posted about this bug, and others, over a year ago (8/12/2015) and it's still there. It was one of the reasons I came up with my text scrubber program.
@WBS00001
Good to see you are getting closer...step by step!
I also realized that the motion from within ARC seemed to work a lot better than a directly translated motion, I was also guessing the delay is caused by the network vs in the Blender example a com port was used, so data transmission was a lot faster. As you mentioned its milliseconds piling up to the point where things get messy!
Also I made a mistake on my side when I jammed the robotic arm rig together while being on the train I changed the FPS within the 3ds max project...I was rolling the idea back and fourth in my head whether or not a high framerate could cause problems in data transmission and I reduced it from 30FPS to 20FPS.
I am really sorry that I forgot to tell you about this idea...so the motion in our testing scene is 100 frames long and is set for 20FPS meaning that it is a motion lasting for 5sec long...which sould make it 50ms for each frame right?
So this would mean each frame would get a 50ms sleep() period...
I just did some testing and it does not work at all, as you said 33ms seems to be to slow already...so if I put a sleep value of 50ms the script takes 15sec to execute instead of five which it is supposed to! confused
The 10ms stop seems to be pretty close but it runs kind of too fast...3sec instead of the five seconds it should run! eek
Still could not figure out why the sleep() has such an unexpected effect on the animation...but as you said you are on the way to try a different approach I just linked the motion rendered, so you might have a better comparison to how it affects the real world model!
I made a 3ds max scene with EZ-Robots JD, it comes with an animation that you can see on the video I made for timing referrence, but it is also fully customizable if you want to build your own motion!
It is just been made to have a common testing ground to push our idea to transfer animation from this 3d application into ARC, so only the head and the arms are setup! No IK is added yet...but it should be fun to try!
It does export the animation but it does not export a functioning rig...
But thats how .fbx works I guess! The dependencies should still be there I figure!
@fxrtst Thank you for the links. They were most informative.
@Mickey666Maus What I have seen of the code involved in the links fxrtst provided is that all of them are using the same basic method we are using in the 3ds project. For example, the Blender project simply sends the servo position to the controller card as the virtual servo moves. The difference is that it does not use the network to do it as we do. And that makes a big difference in the smoothness of the operation. However, there are steps that can be taken to smooth out the operations when using the network method as well. Some may be mathematical in fact. But I'll explore them a bit later. For now I'll concentrate on doing better whit what we have, as described below.
Anyway, all that got me to wondering would happen when I use the file generated by the Maxscript directly in ARC. So I whipped up a quick ARC script to read the file and run the servos accordingly.
What I found was that the servos run much smoother (as expected) when the servo commands come directly from a file instead of coming in through the HTTP Server control via the network.
Additionally, I found that the 33.3333 sleep period between frames (groups of servo positions) was too long and causing some of the rough movement. When I changed it down to 10ms, for instance, the movement was smoother.
This, in turn, led me to the realization that we did not need to send the sleep period every time we sent out a servo command. Something I should have realized before, but was too blinded by science to notice it I guess.
So now, I just send a sleep command once at the beginning of the output and that's it at first. Unless and until a change in sleep period occurs, only groups of servo position commands are sent. This allows for faster transmission and can result in smoother operation. Also, the sheer fact the Maxscript program is sending out groups of servo position commands, is a delay in itself. It will be some X-milliseconds before another command for a given servo will be sent again as the other servos are processed and sent. The more servos, the greater the delay. That can have a pronounced impact on the smoothness of of servo operation. However, that can also be used to calculate the appropriate sleep period. The more servo positions being sent, the lower the sleep period. Such a thing can be calculated either at the ARC end or the Maxscript end. For now it will be at the Maxscript end.
The tests so far have been with only 3 servos. There will be much greater delays when 23 servo positions are sent. I'm thinking I will need to introduce software steps that will check each servo for a change in position and not send anything out for servos that have no change in position, as opposed to sending every one out every time regardless. Basically using the delta compression principle of only sending data which has changed from the last time data was sent.
I will enter new code in Post 21 when I get things going on the Maxscipt end, and I'll post the ARC script I am using to test the direct reading of the file method, when I am done with testing.
EDIT: Oh yes, I forgot to mention, I had to save the servo positions in the Movement.txt file in a different format from the proper one for ARC script. Instead of Servo(D1,60) I had to use Servo,D1,60. This is due to an ongoing bug in the script interpreter. Anything in a string should not effect the code. However, a close parenthesis symbol in a string will be interpreted as actual code. If you try to use it like that you get an error saying you're missing a parenthesis. So you can't have one in any string. In this case, that string would come from the Movement.txt file and the reason for the change in format. It is read Okay, but as soon as some instruction tries to act on it you get the error. Since I had to change the close paren to something else, I decided to use a comma because there already was a comma in the statement and I was using that comma in the Split function to grab the data out of the string. To make it simpler still I also changed the open paren to a comma.
I posted about this bug, and others, over a year ago (8/12/2015) and it's still there. It was one of the reasons I came up with my text scrubber program.
@WBS00001 Good to see you are getting closer...step by step!
I also realized that the motion from within ARC seemed to work a lot better than a directly translated motion, I was also guessing the delay is caused by the network vs in the Blender example a com port was used, so data transmission was a lot faster. As you mentioned its milliseconds piling up to the point where things get messy!
Also I made a mistake on my side when I jammed the robotic arm rig together while being on the train I changed the FPS within the 3ds max project...I was rolling the idea back and fourth in my head whether or not a high framerate could cause problems in data transmission and I reduced it from 30FPS to 20FPS. I am really sorry that I forgot to tell you about this idea...so the motion in our testing scene is 100 frames long and is set for 20FPS meaning that it is a motion lasting for 5sec long...which sould make it 50ms for each frame right? So this would mean each frame would get a 50ms sleep() period...
I just did some testing and it does not work at all, as you said 33ms seems to be to slow already...so if I put a sleep value of 50ms the script takes 15sec to execute instead of five which it is supposed to! confused
The 10ms stop seems to be pretty close but it runs kind of too fast...3sec instead of the five seconds it should run! eek
FPS Converter
I will wrench my brain now to try and find out why this is the case...
Still could not figure out why the sleep() has such an unexpected effect on the animation...but as you said you are on the way to try a different approach I just linked the motion rendered, so you might have a better comparison to how it affects the real world model!
I made a 3ds max scene with EZ-Robots JD, it comes with an animation that you can see on the video I made for timing referrence, but it is also fully customizable if you want to build your own motion! It is just been made to have a common testing ground to push our idea to transfer animation from this 3d application into ARC, so only the head and the arms are setup! No IK is added yet...but it should be fun to try!
You can find the .max scene here...it was a bit bulky for a direct upload!
JD_Rig
@Mickey,
One question, can you export the animation (JD) to fbx file ?
Do you know if a fbx file as all the components plus the motion ?
@ptp I can export it as an fbx file...it should have everything included! Will do it right now!
It does export the animation but it does not export a functioning rig... But thats how .fbx works I guess! The dependencies should still be there I figure!
Give it a try!
JD_Fbx