rgordon
USA
Asked
— Edited
Resolved by Steve G!
I have not been able to find a reference or list as to what controls or items are limited for use with board (0) only.
I know the Movement Controls only operate on the first board (board 0) but, are there others as well?
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.
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.
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.
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.
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
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.
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?"
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?
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
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.