I am unclear as to what you mean by "motor control". Are you referring to the AutoPosition with Movement Panel control?

I think the OP is asking about hbridge? If so, it's a misunderstanding of movement panels.

A robot can have only ONE movement panel, for obvious reasons. This allows the project to know what forward means. Or what left means. Or what any direction means. It's not a limitation, it's a logical design.

So the answer to your question is much simpler than you are assuming. You're going to go "doh!" When I tell you...

But the answer is to create an ezscript for each hbridge - because you absolutely do not have 12 hbridges for moving your robot - so obviously you don't need 12 hbridge movement panels :)

Create a script for each hbridge.

More information about movement panels can be discovered in the learn section.

I still think there are use cases for multiple movement panels (robot swarms, master/drone, snakebots maybe) but I also understand the challenges that brings to the automatic script controls like forward/reverse as well as automatic linkage to joystick, keyboard, and wii controls.

Perhaps another plugin idea for me to start poking at if for nothing else than to prove the point.

I am really hoping sometime this summer to find the time to learn some C# and start making plugins. I keep saying that, but it will happen eventually :)

Alan

I agree, a second one would be ideal. At least for me. I have a crazy idea i'd like to do with Cy. While I am using the parallax HB25s controller/motors , I have my Movement Panel calibrated for "Indoor" use (wish the motors would run on better sync-another issue) but I also want to run Cy "Outdoors". Being outdoors means the motors would be able to run alot faster. So slow indoors, but fast outdoors. I would too love ot have two movement panels to be able to setup for either mode. Then I would use a photocell to detect the different light between indoor and outdoor automatically (in theory). Unless someone has already done a script to do two or more motor speeds? confused

Adding a second Movement Panel is trying to insert a circle peg into a square hole, because it's an impossible and irrational solution, it literally cannot be done because it is absolutely impossible - it is impossible to have two movement panels because Forward() would have absolutely no relationship to a movement direction. The camera control would have no idea how to move to follow an object. The joystick control would have no idea how to move the robot. etc etc etc etc etc

An example of how impossible it is to add a second Movement Panel is..

1. Imagine you have 4 children
2. Name all the children "Bob"
3. Now tell Bob to take out the garbage

Also, having a second hbridge Movement Panel (even if it were to somehow be possible) would not assist the OP request. This is because the Movement Panel contains buttons for FORWARD, LEFT, RIGHT, REVERSE, and STOP. The HBridges in the OP configuration do not have 4 channels, neither do they control wheels that apply to any direction - because it is controlling actuators, as specified.

A direction is FORWARD, LEFT, RIGHT, REVERSE, STOP. Those are directions, much like how your body would move in the real world.

Due to the OP mentioning "actuators", the solution is to use scripts.

Now, there may be an appearance concern of having multiple scripts on the screen - in that case, use the Mobile Interface and have a nice control panel.

I can no doubt create additional HBridge controls that are not registered as movement panels, but that would not be the solution? Specifically when you're ability to use the Mobile Interface Builder provides a much more elegant and visual appealing solution.

@RoboHappy, to control speed of HBridges, the PWM controls the speed. This is documented in the HBridge Movement Panel (PWM) manual. You can access manual pages for any control by pressing the ? (question mark) next to the X (close) button. Here is a direct link for convenience: https://synthiam.com/Tutorials/Help.aspx?id=192

And to understand how PWM works, here is the manual page for the PWM control (which is also the PWM() command): https://synthiam.com/Tutorials/Help.aspx?id=164

For additional assistance, please consult this short video demonstrating how to add two buttons to the Mobile Interface to control an HBridge:

The assumption for this tutorial is:

1. INA is d0
2. INB is d1
3. ENABLE/PWM is d2

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

PWM(D0,$speed_set)

$speed_set = 100 #full speed

PWM(D0,$speed_set)

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.

Voila!

@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). later!

Yeah those 3D printers are sure attention hogs!

@DJSures

Quote:

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.

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

Alan

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

Alan

@thetechguru 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.

@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?

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!