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