I'm finally getting back to my project after many months. I searched the forum on my question but I thought I would post here so I'd have the most recent information
So I need to add controls for seven 12 v motors (4 are actuators).
Does EZ still only allow one motor control per project w/o doing scripts?
If not, are there plans in the future updates to allow this?
Upgrade to ARC Pro
Become a Synthiam ARC Pro subscriber to unleash the power of easy and powerful robot programming
Thing is, a PC project is a very different animal, but it too can only have one movement panel. A PC project can access multiple robots. Each can be controlled individually. In this regard it would seem multiple movement panels would be appropriate. Like the non-movement AutoPosition panels, each Movement Panel could address a different board. Would this be a possibility?
If you wish to add a non Movement Panel version of the auto position, you may do so in the add control menu.
For example, in my Ted talk last week - you would have seen me control 5 robots (3 six, 2 roli) with a single wiimote in a single ARC.project. I'll post the project for you...
My bot is not mobile (around 200 pounds) and around 6 feet tall. The motors control:
Arm actuators (2)
Mechanism with two motors
All are 12 volt. My goal is to simply turn them on, stop, and then reverse. At this point I just need "puppet" control. I plan to get more imaginative later.
Variables are global so you can change $speed_set on the fly in other scripts and the custom Movement Panel will immediately change the speed of your motors... if your photo cell detects a lot of light... set $speed_set = 100 else $speed_set = 50.... very simple...
Use the hbridge Movement Panel with pwm for the actual physicals direction movement of the robot. That means the wheels that move the robot, i.e. Forward, left, right, reverse, stop. Those are directions and that means the direction the robot moves. So use the hbridge Movement Panel with pwm for the wheels that move the robot.
Now add a mobile interface using the example video that I presented earlier. Add buttons for controlling the waist, head, arm, etc.
With the mobile interface you can easily add a nice background image as well. This makes the program look nicer and be easier to use.
Thanks for the info. I figured as much, but was glad to get a better explanation and insight!
Been awhile since Ive done any coding for CY, kinda forgotten alot, been too busy with my new toy (3d printer).
Right. And that's what I have been doing. Except for the Custom Movement Panel since it can't be used in conjunction with any other movement panel. Can't even have multiple Custom Movement panels.
All this seems to be predicated on the theory of 1 project = 1 robot. That is true for the mobile interface, but the PC version can control multiple robots at the same time. This means that is is possible to manually control multiple robots at the same time. One can make a kludge of scripts which can perform this function for boards other than zero, but why? if it existed, you could simply use an additional Movement Auto Position panel which had a board selection option like the Non-movement Auto Position panels do.
Even in your project you weren't actually controlling 5 robots individually in real time with 5 Custom Movement panels. For that matter, the one Custom Movement Panel appears to be controlling 2 or 3 robots at the same time. And that's fine as far as it goes.
Obviously it would be quite difficult to manually control 5 robots from 5 separate Movement Auto Position panels with all of them going at the same time, but, just 2 would be doable. Even 5 would be okay if you were only moving 1 or 2 at a time.
The point is that being able to manually control more than one robot at a time on the PC is a viable option. So why not multiple movement panels to accommodate this?
Use the LoadProject() script command to switch between the projects.
The only issue is maintaining variables. You would need to write all of the current variables to a file (or do the pushvar() and pullvar() if those commands work yet - they didn't last time I checked -- so you could push them to the cloud as long as you are in client mode and have internet access) and then have the init script of the other project read all of the variables.
You'll also need variables for all of your servo positions so you can read them in and set them in the init. Might get some jumping servos when the project first connects. Will need to do some testing to see how viable this solution is.
I would still prefer to be able to have multiple movement panels in the project, and a ControlCommand() to set which one is currently active (I also have at least one use case where both could be active and both responding to the same script and tracking commands, but that use case is easy enough to do in scripting).
Or is the issue something else entirely? What am I missing?
I have uploaded a project called "JD and Six" which illustrates this concept using 5 scripts to represent the 4 directions and Stop. Each Auto Positioner even has the appropriate image and assigned servos for that particular robot. JD runs via the normal Movement Auto Positioner and Six runs on the other one. With it I can manipulate a JD and a Six totally independently. Why can't we have an Auto Positioner type with 4 arrows and a stop already built in to do the same thing?
DJ says "impossible", but I don't think he has really thought through all of the use cases and possibilities, so I would re-phrase as "more trouble than it is worth when it is easy to achieve the same functionality in many ways without him needing to re-write core functionality and risk breaking things that work well now".
Thanks for the explanation. Yeah, that's kind of what I thought. It seems to stem from the philosophy of 1 project = 1 robot. Thing is that view is contradicted by the Non-movement Auto Position panels and the instructions that can be made board dependent. Not to mention the fact that there can be things like multiple video controls. You can define your own variables in some controls now to boot, making one independent from another.
Perhaps a change in terminology is in order. If board-selectable Movement Auto Position controls were called something like "Manual Control" or "Custom Control" it might go down easier. Having such a control available would allow for custom interfaces that can be used independently of any associated Non movement Auto Position control.
Another alternative could be something like the Mobile control panel has. A way to build custom controls by selecting images and combining them in a small window. Like the Mobile Interface, it could allow for the introduction of user generated images as well. Each image would have a script associated with it. Which EZB-4 it is associated with could be made apparent by the title and board selective statements in the script. To directly associate it with a given Non-movement Auto Position control, the script would simply use a Command Control statement from that particular Non-movement Auto Position control. So there would be no need to have a board selection option. It would be helpful to allow for text labels as well. In this way, one could have controls grouped as desired. This, as opposed to, the current method of the movement control portion itself being attached to the Movement Auto Position control. That would also allow for the Non movement Auto Position controls to be placed in one virtual window while the main control panel would be in another.
And, no, I don't wish to try to make a Plug-in for this . I just don't want to go through that process. And is is a process. It has to be registered and go through a formal posting and maintenance procedure. Of course that is necessary and I have no problem with it, I just don't want the bother. Nor the headaches associated with on-going official maintenance. Between my robot building, violin and piano lessons and practice, painting, software creation, and other assorted projects I have going, I just don't want to spend the time. It's much easier for me to write a program in a language I know well, and tie it to the ARC through a text file. I already have a well developed interface for doing that, even using associated Windows .ini files. Which, come to think of it, is probably what I'll do in this case to get what I want.
Sorry for hijacking this thread. I'll stop now.
I don't recommend using the toggle but the commands used should answer what you need.
Also my H-Bridge write up should give more information on what needs to be set to on/off etc. to tell the H-Bridge what to do. That's here. While based on the L298n you will find most H-Bridges will function in a similar way.
Using both the project and the explanation on H-Bridges should help you achieve control of multiple H-Bridges in a single project without the confusion of using a movement panel.
Note: The project and write up are old and may use old syntax. There may even be better methods now, or plug ins which can be used for simple single motor direction/speed control via a H-bridge (I've not really kept an eye on changes lately).