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

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

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

Alan - if you want to write documentation, we can arrange something. The trouble is going to be how quickly the documentation changes due to new features :). That's why we have self-documenting software. So you click on things, or hover question marks for the answer.

Mostly i believe what people are looking for are examples - and that falls under content. Historically, we can document the world and people will still ask "how do i do this?"

I am going to disagree somewhat.... I learn more when I tinker as opposed reading boring manuals... I really just want the "Coles" note version... I learn much more from doing not reading... I do agree with having examples, however....

The solution to documentation with examples is to cross-link objects and controls so they can be referenced in the use case. For example, click on a control manual page and scroll to the bottom. Any use-cases from tutorials are linked to that control.

Also, something that is often over looked in EZ-Script syntax is the Examples folder that installs with ARC. As far as documentation, i'm quite confident ez-robot has a lot more than anyone is used to. And, it's all very easily accessible online and in the software. It's pretty hard to get lost - specifically when everything is cross referenced.

You could argue that a few attributes are missing, such as "what controls use multi boards", but a similar argument of "what controls are hazardous to your health" can be disputed - considering the likely hood of either question being asked is in a low decimal place below 1%.

Continuing forward with content examples is by far the most productive use of documentation with technology.

When a question has been answered on the forum, a polite message box displays a suggestion to create a tutorial on that topic. It's one way to document your own findings for future reference, with the added feature of giving others the ability to use the resource. All user tutorials are linked to controls for cross-reference.

If it would be useful, I can have James organize another user tutorial marathon in exchange for ez-credit?

Quote:

Alan - if you want to write documentation, we can arrange something. The trouble is going to be how quickly the documentation changes due to new features Smile.

It isn't like I really have the time either, but after I do the multi-EZ-B in one project tutorial I signed up for, I may take a stab at punching up some of documentation for some features that I think the documentation is a little light on (interestingly enough, it is a lot of the older features that need the most help).

Alan

@DJ- I have been an Instrument and Electrical Technician for 30 years now and my workplace life revolves around having good solid up-to-date documentation. College, (1980's), was focused on digital electronics. Logic gates and passive support components. I will admit it gets tedious sometimes pouring over manuals and schematics to find information on something I am troubleshooting or building. However, to me, this is an essential thing. When starting a project, I plan it out to the best of my ability so that I wont get deep into it only to find out that I missed something and now I will have to spend (waste) a lot of time tearing things down and reassembling all over again. Not to say that it does not happen but, time is precious to me. Not getting any younger :D.

Here is the space shuttle.....don't bother with reading the manual....just push buttons and try things till ya figure it out.... stress

Nope...can't do it....gotta have me books.... ;)

Robots and electronics are my true passion and EZ-Robot has opened up a whole new world for me. It is an exciting time to be alive! And thanks to DJ and his team, robotics has been taken to a new level of amazing potential. Keep up the good work.

Thanks Steve for looking at this....