Asked — Edited

Time For A Script

I want to start writing some scripting, but don't know where to start. I need a format to follow to know what I should consider as first thing, second, etc. I know the following things I want to do on startup but don't have an example or guide to look at.

Here is what I want to do: 1) Set all servos to a home position at a slow speed so as not to damage anything. 2) set maximum speed for each servo. 3) sequence through the AutoPosition functions as I want or as the inputs allow (voice commands or sonic sensors etc.) 4) At end go to shut down mode and set all servos to a home position.

I am not looking to have someone write the code for me, I am just asking for a place for an example or show me a format.

I need to start somewhere. I know others will benefit from this advice.

Ron R


ARC Pro

Upgrade to ARC Pro

ARC Pro is more than a tool; it's a creative playground for robot enthusiasts, where you can turn your wildest ideas into reality.

#9  

@Andy, Post the vid to Youtube. Then use the "Add Youtube Viedo" button below this message and cut and paste the link to your Youtube vid into the box that pops up. Save it and your video is posted here.

@WBS00001, Good questions and your view has been echoed in other posts. I think DJ sometimes forgets us common folk are not as brilliant and intuitive as he is and assumes we'll just "get it". eek

#10  

After a bit more searching in C# code, I have divined the Operations of the date and time functions. I have divided it up into 2 sections. The list of the functions with brief extras, and a NOTES section with more detail. You can find the writeup here: https://synthiam.com/Community/Questions/8317&page=2

At or near the bottom.

#11  

My wish for an EZ Robot Script 101Tutorial.

When a new script writer sits down to write a script, often he/she has no idea where to start or what their robot can do. Maybe they have built some Auto Position frames and actions, but maybe not. This tutorial would be used to open the door to a world of robotics. it would give guidance to the basics and progress to the more complex. The Robot examples located elsewhere would then have more value and could be used to learn from.

My thoughts:

Here is an example a new script writer might want for a first script. When turning on a robot, JD for example, all the servos quickly move to a home position. If the last position, the robot was left in, was not near the home position, the servos move very quickly to their position. Obviously this could cause a problem, and maybe damage. In section 1 of any tutorial this should be addressed. This has been presented and answered in this post, but it would be nice to be in a tutorial.

Section 2 could be simple movements of servos showing how to control speed and movement, etc.

As the user progresses through the sections, the scripts get more involved and complex. One script builds on the last script written. Camera usage, tracking, movement panels, voice commands etc. get covered and an example given using previous knowledge learned. (Rich touched on this in his "Richie" Tutorial). Community members could drop their examples into the sections to help show how functions work.

This is something I think would be of value to those who have no understanding of robotic but want to learn. It also show the power and features available in the EZB controller / Software.

My Thanks.

Thanks to anyone who reads this and agrees. It was something I feel would be helpful to all.

Ron R

#12  

All programming languages are basically the same... in that they can do pretty much the same thing, albeit using different terminologies and syntax... I started out using (20 years ago) the Basic Stamp microcontroller, then the Basic Atom microcontroller (more powerful than the Stamp) and then the Adruino.... And finally ARC scripting (which is the easiest of them all)... Once you learn one, the rest are easy....

@Ron, just learn the syntax and let your imagination guide you. There is no right or wrong way to code (just more efficient ways), just like there is no right or wrong way to draw a picture.... If the code doesn't work, you'll either get an error or what you expected the code would do... it didn't do.... Make changes and try again... This is the learning part.

Just start out simple.... copy sample code and play with it... ARC has a plethora of sample code built in as examples....

How do you think I learned?... no one taught me. I didn't go to school for programming.... I learned from screwin' around with other peoples sample code.... Eventually you get proficient enough to write your own stuff...

How did you learn to do your job? Time and paying attention, right?... My advice is to start with code snippets and see what they do and how changing them affects the outcome when you run the script... (Like I said, ARC is full of code examples....)

#13  

Allow me to begin by saying I echo what Richard R. said in his post. The only thing I would disagree with would be the statement that there is no right or wrong way to program. But that's because I come from a professional programmers point of view. As far as the person who is new to using the script language, however, I would agree. As the saying goes, just do it. Right or wrong, good or bad, just do something.

In the PC world, a bit of advice where programming is concerned is "try it and see what happens. You can't break it." For the most part this is true. In robotics, however you can break it. If you do, then you shrug and say, "Well, at least I learned something". Hopefully, it's not your finger or an eye.

Still, there is a lot you can do before you actually apply any code to your robot. And, in that mode, you can't "break it". Use the debug window and copious Print() statements sprinkled in the code to see what is happening. Go step by step and break down your code into small sections to try things. You don't have to write the whole opus in one go. Or even in one script for that matter.

Now, one thing to keep in mind where ARC is concerned is it's basic philosophy: Use Controls to do things. The script language is just for those things you can't do with just controls alone or there is no control for. With the new Plug-In feature coming, there should, eventually, be fewer and fewer cases of that. Fundamentally, it is like the axiom where using computers is concerned. It says that "If you are adding hardware to a computer device, you are defeating the purpose of using a computer in the first place." Of course, that's not always possible because, as things stand now, the computer simply isn't fast enough to do everything it could. So you end up adding some additional hardware. In a similar way, using the script language to do something is defeating the purpose of using ARC.

Think of the Controls as pre-written script programs. All you do is copy and use it. In reality, however, they are not written with the Script language. They, and the script linguage itself, are written with a higher level, fully implemented programming language. Thus they can do more than anything in the Script language can do. They have access to things the Script language does not. The Script language is primitive by comparison. It is meant to be.

So, before writing that super duper script program, think. Could I do this with a control instead? If so, use it. Don't reinvent the wheel. Or, at least, call that control from a script. That's a tutorial in itself actually.

The Autopositioner control is a prime example of that. The one major fault of it is that it always works with all the servos in every frame. At the least, the same set of servos. You cannot just set a given Frame up with only some of the servos. It's all or nothing. That becomes a problem when all you want to do is move an arm a certain way, regardless if the robot is sitting or standing. That's why, in addition to the main Autopositioner, I have separate ones for every limb and pairs of limbs (and the head). Since you can't resize the window for that control (Hint, DJ), you fill up a screen fast, even with 3 virtual screens available. One robot takes up the whole screen.

Alternately, that is where a script can come in handy. With it you can move just one servo to wherever you wish. So, in that regard, go for it!

Finally, as far as tutorials are concerned. People would have different approaches to writing them. People like me would not be able to restrain themselves from teaching "best practices" along with the writing of the code itself. That's because I come from a program maintenance as well as a programming point of view. I consider the best way to be able to maintain the code, long term, as well as write it for readability. Writing good code is not just about making it work. So I would probably not be a good candidate to create such tutorials. So ingrained is it all in me, I would probably be incapable of writing a "For Dummies" type of programming book. I would be conflicted the whole time I was writing it. The editor would fire me after the first draft of the introduction alone. :D

#14  

@Richard R & @WBS00001 Thanks for the replies. I got a lot from your statements. The " Just go do" is important. Like you both said, "if it doesn't work, try again"... Another big take is, use what is already built. I really just need script to sequence what I need and when, not build it all. I think I finally got it! I don't have to re-invent the wheel.

I have tried some scripts and a few work and a few don't but I am having fun, and learning.

Ron R