Algodoo

EXCELLENT JOB! THIS IS AWESOME!

Just wondering where you store the steps? I haven't found it yet.

EDIT -- I think I found it... "scene.my.angleList" Right?

Yes, thanks.

One suggestion with efficiency in mind. I noticed that your code continues storing steps even while no commands are being given. In the real world, that would be a waste of memory, and would make the program data files unnecessarily large. My suggestion is to store steps only when any of the motion keys is being pressed. Just a gut feeling that this would not be too difficult to do. If you have no interest in doing this, I would be happy to work on it myself because this is a truly awesome scene. In my opinion it is your best work!

That is a good idea. In the real world memory is cheap, but time is not cheap. Eliminating dead time would make the robot movement more efficient. The only downside I see is if you were timing the movement to work with another process.

Feel free to make any changes you like. The only thing is, I may steal them and use them in future revisions. This way we can build on each other's ideas.

In order to make the idea work you probably need to determine when none of the motion keys are being pressed. The "Key Down/Up Phunlet" shows one way to do this.

Okay, I'll tinker with it and see what I can come up with. Be advised that this will always be YOUR scene, and if I publish any changes, I will make certain that everyone knows that you are the original designer.

After taking some time to look over your code, I realize that this will be a little more difficult than I first thought. There are a couple of issues to consider that might make the difference between a somewhat simple modification, and a complete redesign. Right off I noticed that the playback speed is substantially faster than the realtime record speed. Have you given this much thought as to whether or not the playback should be the same speed as the record speed?

Another "major" consideration is how I decide to handle recording the trajectories. About 12 years ago, I had the oportunity to program a real robotic arm (made by Motoman) which was capable of carrying loads of hundreds of pounds. It had a reach radius of about 10 feet (if memory serves me). We programmed the movements by translating the end-effector to a desired x/y/z position, and then pressing the "store" button which takes a "snapshot" of that position. You then translate to another position, actuate the end-effector if needed, and then store it again. during playback, the software moves the arm with a speed and trajectory profile that is required to safely move the end effector, and avoid any obstacles that it knows about. So, the bottom line is, the programmer tells it the desired x/y/z positions and the desired actuations, but the actual trajectories are determined by the computer based upon what it knows about obstacles, speed limitations, and other considerations. Your robot arm is different in that it not only records the x/y positions, but also every move that the operator makes during the recording session. If I wanted to change your system to the "snapshot" mode, where it only records positions and not trajectories, then it would require an entire rewrite, so I'm not going to go that route! I want to keep the changes as simple and straightforward as possible. So, it would be helpful if you could briefly describe how your script basically works, so that I won't need to waste time reverse-engineering your code. So, when you have time, could you PM me the basic theory of operation? I need to know what lines of code does what function, etc.

If you do not want to do that, or if you simply do not have the time, then let me know and I'll try to figure it out on my own.

Thanks very much!

Q: Have you given this much thought as to whether or not the playback should be the same speed as the record speed?
A: No. At first I had them the same speed, but then I thought that the faster the playback the better. The code that sets the speeds is here:

e.laser._action == "record" ? {scene.my.offTime = 0.1;...
e.laser._action == "play" ? {scene.my.offTime = 0.0;...

Q: ...basic theory of operation?
A: Four angles define the position of the robot arm. These angles are calculated based on user inputs. The angles are periodically saved when recording.The angles are set during playback. The angle variables reside in the bendTarget property of each joint. The angle calculating code is in the green x,y box. The recording and playback code is in the brown action box.

It would be nice if it can record smooth mouse movement, so I can play it like in my old basketball robot scene but with replay!
Great scene.

s_noonan - Okay, you've given me enough detail to get me started on making changes to the scene. Thanks!

Kilinich - Great idea about recording mouse movement! Also, your basketball scene is more than amazing! It's almost as if that robot arm has a life of its own. This is probably the best AI code of all the scenes on Algobox!

Xray - Since you got me thinking about eliminating dead time, I decided to give it a shot. I was able to do it with few changes, but I will wait a while in case you wish to post your solution first. I created a variable scene.my.moving that is true while the robot is moving. I then ANDed scene.my.moving to the read code like this: "_rwState == "read" && scene.my.moving ? ..."

s_noonan - I've been very busy with my X-ray repair business and so I had little time to work on Algodoo scenes. Go ahead and publish your update. I'm very interested to see what you've done!

Hey, your update works great! GOOD JOB!

I found a couple of bugs:
1. After recording moves (#1 Key), you must press the #2 Key (Stop) before pressing #3 (Play). If you go directly from #1 to #3, the steps do not stop at the last step recorded, but will continue running past it, somtimes causing erratic moves.

2. You can manually move the axes during playback which causes the arm to go crazy. You should disable the manual moves during auto-playback.

Suggestions: Instead of labeling the three modes "Action", I suggest you label them "Mode". You currently have 3 modes: Record, Stop, and Play. That sounds more like functions of a tape recorder! Much better to use industrial type words such as: Learn, Standby, and Auto, OR Store, Standby, and Recall. (Or find some other words that sound like they belong with an industrial robot.)

EDIT: And if you want to make this project look really cool, find some textures that will make it look like a real robot arm instead of like a cartoon. (Sorry, I'm giving you more work! )

Xray - I'm finished playing with this for a while. I will not be adding textures any time soon. Feel free if you would like to spiff it up. I'm more about function than looks. Compare my Wall & Edge Sense Car to ravenplucker's Edge-sensor bot and you will see what I mean.

s_noonan - I see what you mean about those two edge sensing cars. Ravenpluckers is very complex and over-engineered (although a brilliant piece of machinery) and yours is rather simple and efficient, and does basically the same thing as his does. Very ingenious indeed! Even though most of my scenes are 90 percent script, and 10 percent mechanical, I have a deep respect and admiration for beautiful and elegant mechanical devices. Some mechanical scenes on Algobox blow my mind because of their complexity and how well they function.

Anyhow, I am VERY impressed with the work you did on this robot arm. I so impressed by it, that I would like to add some of my own modifications. Now that I'll have some free time over the holidays, I'll see what I can do with it to improve it. I also plan on working on Kilinich's Battle Boats contest. That level of coding is beyond what I am used to, but I'm not afraid to give it a shot. It should be fun trying to win!

Thanks, and HAPPY HOLIDAYS!

I am in awe of Ravenplucker's designs, I suspect our minds work quite differently.

This is not good.....this is AWESOME!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

WOW! I love this scene! A mashup between your "teaching" and my "G-code interpretor" used in my 3D CNC would lead to the ultimate Algodoo scene lol!
Combining the two would make it possible to do what Xray said: Teaching by recording only "strategic" point. When running the "record", the interpretor would then interpolate the path between each point. Tell me if this sound cool to you. If so, I sure would help you out. I might try to incorporate teaching on my CNC scene, that would be cool also!

Wow... Just wow... This isnt good... This is...
OMEGA ULTIMATE ABSOLUTE BEST OF THE BEST DESIGN
Okay im going a bit carried away XD