Algodoo

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!

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!

It took me a while but now I get it. The laser detects the "bad guy" car which throws up a barrier to prevent him from robing the bank. But the barrier lets the cop car through because they are the good guys.

Nice scene!

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! )

It breaks when you move to the top of the screen. Sorry, not very good design compared to other scenes that do the same thing. Needs work to fix the problem, and also you should make it something special that no one else has done before.

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!

Faytree -- Instead of those ugly coins, why don't you use textures of real coins of your country? A good engineer cares not only about function but about form and aesthetics (how good it looks). When you use textures to spiffy up your scenes, it can make the difference between being a "not too impressive" scene, and being a "Really awesome" scene! Just a friendly suggestion.

Generally nicely done, but the playback seems way too fast. For example, when I wiggle one finger from side to side (in a waving motion) say, about 10 times, the playback happens so fast that you can hardly see the finger do the motions that you recorded. (I was just thinking that the playback might be fast for fast computers and slow for slow computers. Just a guess, but you should be able to control the playback timing with sim.time so that the playback time is consistent regardless of the computer speed.)

You should say "Press and hold Enter" to run the animation.

This game is hard! Every time I put the card into the box, it sinks down to the explosive material, and BOOM! Can you really place it into the box so that it doesn't blow up?

I threw up all over my keyboard. THANKS, FAYTREE!!!

You shouldn't make fun of some dude who was born without any arms or legs. Shame on you!

Nice fix, and it works very well.

Not to be picky, but it wasn't intuitive to me that I was supposed to use my drag tool and rotate the red circle to change the frame rate. Suggestion: Add text that explains how to change the frame rate (such as, "Rotate circle to change framerate"), or use some other method that doesn't require explanation, such as a slider, or two keyboard keys that adjust framerate up and down (Q & A?, E & D?, etc).

EDIT -- As an afterthought, you can use your hover mouse trick to change framerate!

Excellent scene.

Excellent scene, and timely for the season. And my grandkids love it!

Damn! You did a great job on this scene! The animation is awesome. You got a solid 10 from me.

EDIT -- How do you like my "Disco Dan"?

HUH?

In case you haven't realized it, I had to make his feet very heavy in order to give him stability so that he doesn't keep falling over. M.J. would not be able to dance as well as he did if he had 50KG shoes!

Kilinich -- LOL!! If YOU don't understand it, then NO ONE will!

I don't see any problem either. Looks Okay whether I zoom in or out.


EDIT -- After playing with it some more, I did notice a gray horizonal line that shows on the right side of the texture image when both X and Y are clamped, but it does not show when the texture image is not clamped. So, I believe that Faytree is correct. There does seem to be a bug!

Nothing happens. What is this supposed to do???

I'm not so certain that it's a "bug", but it just may be an artifact that sometimes occurs when some textures are clamped. I tried working with other textures, and they all have a strange artifact above, below, or to the sides of the image. But if you expand the image so that it fills out to the edges of the geometry, then the artifact(s) are not seen because they are beyond the edge. So, even though this occurs, I don't believe that it's a problem worth spending a lot of time on fixing. But of course, Emil will need to be the judge of that.

Steve - I spent way too much time on this already. When the code starts to get so complex on a project that the original designer can't figure out what's going on, then it's time to quit or to re-write it. I made the decision to quit this one!

In reference to your x,y, theta stage, I do have a design for a 5 axis CNC "table". The five axes are x, y, z, and a. The a axis is the rotational (theta) axis. I was planning on using the table with my CNC controller and have it programmable using actual G and M code commands, but as I mentioned earlier, it's way to complex to code all of those commands, and I probably don't have enough years left to finish such a project before I meet my maker!

OOPS! Make that FOUR axes, not 5!

.

Deleted comment.

s_noonan -- I originally thought about using a magnetic compass like this one, but ended up not doing so because it did not make sense. Anyhow, your compass works better than mine because it points to zero even while holding on to it and moving it. Mine doesn't do that.

Yes, I took a look at that function in the console, but I don't understand how it works. Your math abilities are far above mine.

You need to learn how to spell.