Goodness gracious! I should think so. As a long-time software engineer, and frequent teacher of programming, I think I can see why this didn't work. You observed people having trouble with BASIC, so offered them something more low level? That's like taking someone who's struggling to learn to drive, and stuffing them into an airplane cockpit. If the car is too hard for them, the airplane is not going to be easier!
I do applaud you for trying to address the problem, though -- it's true that programming is hard for many people at first. But the only ways to effectively deal with that are to make it easier, or avoid the need for it altogether. A stack-based or state-machine language, while easier to describe to an engineer, isn't easier for a newbie. Something like the Mindstorms visual programming is; as is BASIC with a very good IDE and some tutorials.
(And of course, avoiding it altogether is hard without severely limiting what your users can do, which probably wastes most of the power you were trying to provide.)
Of course you know your business and I don't; I may be way off base here. I hope you'll take it as an attempt to be helpful, whether or not it ultimately proves useful.
You need MIT-level experience to solder an op-amp to the leads of a servo's pot? You might not even need the op-amp if your microcontroller's ADC inputs are reasonably high impedance. Other slightly more complicated methods have been demonstrated of tapping into the chipset and reading the error signal. Most brands use the same internal circuits, so once you crack the brand, it applies to most of their products.
Besides, one has always been able to determine that the servo is not in the place it's supposed to be by measuring the current demand on its V+ side. These and other approaches have long existed for those who want them.
Maybe. I'm sure I couldn't figure it out; I'm just a software engineer with a Master's in neuroscience. If it's that easy, please post details!
No, only for those who want them and know how to find them out. I've wanted them for a year, but until this thread didn't even know it was possible without buying expensive digital servos with 2-way communications built in. I still don't know how to do it; I only have your assertions that it's easy. Can you recommend a beginner-level book or website that describes these techniques?
The concept behind RoboBricks2 bus is to strike a balance between ease of use *and* ease of implementation. The concept is that new users would feel confortable plugging together modules designed by other people, but more experienced robotics people should feel pretty comfortable designing a new module that plugs into the bus as well.
The 5 most heavily discussed options were:
1) I2C 2) SPI 3) UART on top of a) RS422, b) RS485, or c) CAN bus physical layer 4) CAN bus full stack.
The desire for a high noise immunity bus pretty much ruled out I2C (1) and SPI (2). We liked full CAN bus (4), but it was viewed as difficult to implement modules for since it basically needed a pretty complete set of hardware support inside the microcontroller along with some substantial software support. The advantage of using a UART (3) of UART's is that they are both ubiquitous and easy to use. Doing UART support in assembly code is still relatively easy; whereas CAN bus support is not. Thus, UART (3) won out over full CAN bus (4). The choice of RS422, RS485, vs. CAN bus physical layer was based on ease of module implementation. The CAN bus transceivers do not need to have a pin that specifies whether your module is transmitting or not.
The bus is currently using 10 conductor insulation displacement connectors (i.e. 2x5 headers.) The headers are polarized to prevent plugging in backwards. Again, there was a huge amount of discussion about connectors, and the choice of 2x5 connectors was based on ease of use and availability. There are actually two power buses on the ribbon cable -- one regulated 5V for the logic supply and one 6V-12V for direct connection to a battery. Devices that have nasty power surges are required to keep their surges off the logic bus via opto-isolators; this includes motors, servos, Sharp GP2D12's, etc.
The RoboBricks2 bus hardware design is fixed and will not be changed. If you do not like it, please feel free to design your own bus and modules that plug into it. Honestly, I will not be offended.
The software architecture is pretty simple master/slave. Each slave module has a unique 8-bit address on the bus. A master sends out module address select byte, followed by a number of commands to query the slave module. There can be multiple masters on the same bus, but only one can be active at a time. When one master is done, it contacts the next master and hands off control to it. There is no collision detection hardware or software.
The bus is currently running at .5M bits per second. It is felt that this is fast enough for everything but pumping video frames. If people want to do video, they will have to use some other bus.
While the summary above took longer than 15 minutes to type in, it should provide enough of an overview.
With regards to pictures, the only two pictures I could find of a robot that uses RoboBricks2 technology is at Camp Peavy's site:
The pictures are too small to be of any real use. I'll put posting of some pictures on our "to do" list. It will take a week or two before it happens.
Easy isn't a word I used, but you don't ned "MIT-level experience" to do it, either. (Or maybe you do, and MIT owes me a degree.) The process is about as physically easy/hard as modifying a servo for continuous rotation using the older resistor-substitution technique. If you can do that, this technique is in the same category.
The pot in a servo is a voltage divider: ground, V+, and wiper, the latter which represents current position. Basically you connect something that can read a voltage between ground and the wiper.
(Looking for me notes here... Ah, yes, here they are.) I once took apart a Hitec HS-422. Tapped into the pot with a scope, for testing. Yellow wire from the pot is the wiper. Red wire is ground, green is V+. As the pot moves the voltage on the wiper full-swings approximately one volt. Hold back the output of the servo, command the servo to move. You will see the voltage doesn't hange. Let the output go, and the voltage changes.
In an actual small robotics controller, you'd connect these the yellow and red wires to the input of an ADC on a microcontroller. If the ADC inputs aren't high-impedance you probably want to use an op-amp to prevent loading the output of the pot. Since the voltage on the wiper of the pot is likely to change depending on battery level, you will probably also need to read the V+ voltage to the pot (yellow and green on the Hitec).
These aren't details but most anyone with electronics basics can replicate this. The "hard" part is connecting to the pot leads in the servo. You have to figure that out depending on the type of servo you're using. The color coding I describe above is for an HS-422 made at least three years ago, when I did this experiment. Hitec may have changed things by now, but the general concept is the same.
I'm not sure what you're driving at here, but the only response I can think of is "yes, of course." Someone who isn't interested in the technique won't bother. How to find out is probably Google. Now that you know it's possible, perhaps you can do a search and find some hands-on tutorial somewhere that talks about it. Let us know what you find. Here's a link to get you started:
formatting link
Or maybe this thread will encourage someone who needs this capability.
This sounds really cool. I'm still not sure what a CAN bus is, but I believe I understand that UART basically means a serial bus. So you have a bunch of modules that can be plugged together with minimal fuss, sharing power and communications over the RoboBricks2 bus.
I really like the idea of more modular, plug-and-play components. Apart from Mindstorms, I haven't seen anyone else to do this very well -- and Mindstorms is rather limited (as a controller, anyway). If you can do something similar but with more options, and (ideally) with a lower entry barrier (in cost), I think you'll have a big hit.
Yes, and I appreciate it (and hopefully there are others here who do, too). Will these be commercially available, or just public designs, or what?
That's the idea - the symmetrical connector and power+logic arrangement is useful. It's almost a shame that it won't "just work" either way actually! That'd be cute.
I would have made the software protocol a little more sophisticated, adding a discovery (devices + capabilities) protocol and the possibility of sending short packets rather than just 9-bit bytes. With packets, you can drop to 8-bit byts to make coding easier too.
Consider that it's the software pluggability as well as the hardware that matters. There was a good protocol discussed here a while back of which I can't remember the name. The kind of thing you need is to be able to say "identify yourself, #47" and get back a descriptor from a standard set like "H-Bridge, up to 3A, with current sense return data", "servo, 270 degrees range, 180 degrees/sec, 4Nm max torque", or "compass, 3 degrees resolution".
But basically, all it needs is a bit more definition and some vendor willing to make a cheap range of modified servos, sensors and a CPU board (or adapter H/W), and you could get the platform established and moving.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.