Welcome to Synthiam!

The easiest way to program the most powerful robots. Use technologies by leading industry experts. ARC is a free-to-use robot programming software that makes servo automation, computer vision, autonomous navigation, and artificial intelligence easy.

Get Started
Asked — Edited

Adding Multiple Motor Controls

Afternoon All

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 :D

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?


D. Scott


Upgrade to ARC Pro

Become a Synthiam ARC Pro subscriber to unleash the power of easy and powerful robot programming

I'm a bit confused. Is this discussion aimed at the use of the mobile app only?
This discussion is using the mobile interface builder as an example to present a nicer interface in ARC project for running scripts - as explained in my response regarding "an elegant and visual appealing solution" - as quoted
Ok, thanks. I thought so but I wasn't sure. I understand the logic of having only movement panel, but I think it all hinges on the assumption 1 project = 1 robot. Which is the concept behind the mobile interface, and that's fine.

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?
That exists - add the non movement Auto Position panel. You can find out more by visiting the Add Control button of ARC. In that menu, you will find new controls to add to a project.

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...
Here's the project that i used to control 5 robots (3 Six, 2 Roli) with a single WiiMote for my Ted talk on June 17th 2016: TEDX.EZB
Whoops. I didn't give enough information. I'll study everyone's replies but for now here is a little clarification.

My bot is not mobile (around 200 pounds) and around 6 feet tall. The motors control:

Waist rotation
Head rotation
Arm actuators (2)
Head lifter
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.
@RoboHappy ... What you want to do is so simple to do using just the custom Movement Panel and variable(s) to represent speed.... Slow indoor, fast outdoor... as an example using PWM


$speed_set = 50 #half speed


$speed_set = 100 #full speed


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...
Mulberry, sounds exciting!

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.

@DJ, and everyone else:)
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).
Yeah those 3D printers are sure attention hogs!


That exists - add the non movement Auto Position panel. You can find out more by visiting the Add Control button of ARC. In that menu, you will find new controls to add to a project.

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?
Please refer to my previous posts in this thread regarding why having multiple movement panels is an impossible approach.
Most (not all) of the use cases I have for multiple movement could be solved by having two projects that are the same except for the movement panel.

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

Ok, I seem to be missing something here. My issue is being able to control multiple EZB-4s in the same project. That can mean multiples on one robot or each EZB-4 in association with a separate robot. It just seems to me multiple Movement Auto Positioners which would be board selectable would be fine. Each Movement Auto Positioner would be tied to a different connection/board. That would allow individual manual control of each robot. We already have the ability to have multiple Non-Movement Auto Positioners which are board selectable. What's the problem with adding 4 motion control arrows to them?

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?
@WBS0001, what you are missing are that there are script commands and other object functions which are tied to the movement panel. Specifically, directional commands, and object tracking by movement in the camera control. To have multiple movement panels would mean either that those commands would all need to be updated to allow you to specify the panel, or the commands would need to be modified to only address a "primary" panel.

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 :D . 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.
@dj, I'm looking for the Ted talk you were involved with. You say June 17th was that aire date or when you recorded and wil be shown at a later date?
United Kingdom
Multiple H-Bridges can be setup, including toggles to change what moves with the movement panel. I wrote a project a while back covering it here.

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).
@fxrtst it will be online for viewing in a month or so they said. It was live when recorded
Ok great i'll keep an eye out for it!