As far as I know, movement panels as you have mentioned, and sending sound to an EZ-B using the "Soundboard v4" control, are the only controls limited to board 0.

I did start a thread about this very subject a while back, but closed it as I didn't get much feedback to make it work. It's here if you want to take a look.

It is a pity that your post did not get much feedback as it would be very helpful to people like me who are finally getting into using scripts and multiple boards.

I am nearing completion of Questor's base drive section. I have one EZ-B V4 controlling it. I have six(6) Pings and six(6) bumper switches that are for object avoidance/detection on the base section. (Pictures coming soon) Recently I began writing my first scripts for navigation control. After I had all the sensors working I decided to add a Sound Board to my project and it would not work. I have hooked up an external amplifier and I know the amplifier works because I can hear the EZ-B startup and connection sounds coming through the amplifier. However, nothing I added to the Sound Board Control would play through the amp. I then wondered if all the sensors that I was using was causing a resource problem. So I removed the sensors from the project and left only the Sound Board. Then the Sound Board would play anything I loaded in to it. If I added the sensors back it would stop working again. I see now that the Sound Board control will indeed let you choose which board. I guess that I will have to use one of the other two EZ-B's for the sounds.

Here is some background on Questor's base so far:

PINGS

Ping 1 and Ping 3 have scan (interval) times of 200 ms. Looping

Ping 2 is mounted on a servo and sweeps back and forth, stopping briefly at 5 different points. At each point a script performs a GETPING command. Time between each point is 200 ms.

Ping LT and Ping RT have scan (interval) times of 550 ms. Looping

Ping Rear is mounted on a servo and sweeps back and forth, stopping briefly at 5 different points. At each point it performs a GETPING command. Time between each point is 300 ms. Ping Rear is only active when the robot is in reverse.

BUMPER SWITCHES

The front bumper consists of seven switches but, as noted in the drawing, I have some of them wired in parallel so I could save on inputs. So they act as though there are only three switches.

The rear bumper also consists of seven switches but, as noted in the drawing, I have some of them wired in parallel so I could save on inputs. So they act as though there are only three switches.

To further save on inputs, I built a logic circuit that monitors all six bumper switches but outputs a four bit binary coded output so I will only have to use 4 digital inputs on the EZ-B. The circuit could potentially monitor up to 16 inputs and still only use 4 EZ-B inputs. The problem I faced here was the lag time between scans of the switches. If I set the scan interval too fast it bogged down the EZ-B. If I set the scan time slower, it would take to long between when the robot hit something and when the EZ-B inputs finally changed. Even 200ms is to long when you are talking about a 100lb robot. The bumper switches need to stop it instantly. So what I did was to add a timer circuit. When a bumper switch is contacted, a relay activates that kills power to the motors. The timer times for 5 seconds and then the relay resets back to normal. This gives the EZ-B inputs plenty of time to see the change in state. Then make a decision on what to do to move away from the object it bumped into. Hope that makes sense. See the drawing on the next post. Hope I have not bored you to death with all my ramblings.

Here is the base drawing

Not boring at all. I like the idea of the relay and timer combo that you outlined. That's something I could use in future projects. Thanks for sharing the info.

In regards to using multiple boards, I didn't know that you could select a board for a soundboard (although I admit, Soundboard EZB() is isn't something I've used for a long time), but one thing I forgot to mention was that Inbelieve that speech synthesis using the SayEZB() commands can only come from board 0. It is a shame there was not much input on the thread I mentioned, but looking through the ARC manual and script menu, I don't think there's much that cannot be done with multiple boards now.

You can find out what control works with second ezb by adding the control and looking for the option

Really, anything with servos is multi board. It's not a high priority as a documentation attribute - specifically since ARC is self documenting, and was designed that way. You know what something does by adding it. Pre-reading documentation before using something uses twice as much time, and therefore I believe doubles the effort and frustration as well. So, just add the control and dive in! What do you have to lose

After all, what would you prefer - lengthy documentation that makes good bathroom reading material, or constantly evolving new features pushing the limits of robotic technology?

If you chose the latter, then you're at the right place. We're all here to act on changing the world, not write about it.

Quote:

After all, what would you prefer - lengthy documentation that makes good bathroom reading material, or constantly evolving new features pushing the limits of robotic technology?

Honestly, I want both. Good documentation is important for planning large projects, but I know where you are coming from, and at the current size of your business, you can't develop and write comprehensive documentation without slowing down your release schedule.

When you are big enough to hire a full time documentation writer, drop me an email.

Alan

I have to say that I agree with Alan. Same goes in the fact that I know the situation for EZ-Robot weighing up providing detailed documentation against adding new features.

Besides, is that not what we do when a member comes asking for help, especially new members... pointing them to the learn section to read through the documentation of the tutorials, FAQ's and ARC manual before playing about with hard/software, as well as posting information on the forum (such as I tried to do with the multiple EZ-B thread) to help people where they need it, as the forum is a dynamic and evolving user guide in itself. I certainly wouldn't call it "good bathroom reading material". I love playing around with new features, but good documentation is just as important.