Multiple Motor Control - Guest Blogger
Mark_R80 shares the following:
I have created a card that plugs into the input port of a NXT brick and can control 2 NXT motors. By using several card (on different address) one could have a lot more motors then the multiplexer method being developed by MindSensors and HiTechnics.
I have created a card that plugs into the input port of a NXT brick and can control 2 NXT motors. By using several card (on different address) one could have a lot more motors then the multiplexer method being developed by MindSensors and HiTechnics.
Comments
And there are at least two aspects not mentioned in the YT video I'm rather curious about. First, what is the current draw for your controller board. Keeping mind mind that the input ports can only provide about 80 mA, running "20 to 30 motors with no trouble" would seem to imply a current consumption of under 6 mA per controller - is this correct? Also, when you show the controller board, there appears to be no attachment for external power, which seems odd (especially as there are some battery packs visible in the video). Does the system use external power, and how is it provided?
Very nice idea - I really love the ability to have "full" control (both power and encoders) of NXT motors.
very interesting...
Are the electric circuit diagrams and software public available ?
Christian
On the power, each card has it own external batteries and the power for the microchip becomes from these batteries. (the quality of the picture is not good but there is a 5 volt regulator on each card to supply the chips).
Mrk_R80
Driving the boards from their own dedicated power supply is a nice touch (after all, you need it for the driven motors anyway). I wish I understood more about the fine details of I2C - I'd worry about not having the same ground level on the lines for instance. I'm not at all sure what a realistic upper limit is for driving I2C devices from the NXT is. I'm sure even 128 per port is going to be tricky, as you'll end up with signal delay on lines that long that frustrate the communication. I suspect (although do not know) that if you really want to extend the number of motors, doing it with a many-motor board (so that I2C comms are not the limiting factor, as there are only a couple of I2C devices) would be significantly more efficient (there's a limit to how much the NXT can handle internally in terms of monitoring things as well). Can your set-up be easily expanded to have a single driver board handle 4, 8, or 16 motors?
Another thing that wasn't clear to me is where the "mode" behavior is handled. Is that upper level in NXT-G, or the standard FW, or on the boards themselves? For instance, do you have to tell the board to send back the current encoder position (and keep track of it) on the NXT, or can the NXT send I2C commands that instruct the boards to, for instance "move motor A forward 30 counts" or "position motor B to within +/-5 degrees of the absolute position 2065°"?
No. One would have to redesign the printed circuit board with more NXT jacks on it, putting a more powerful processor running more motor would not be better because you would still need to run commands via I2C for each motor. All these commands going to one address (card) or several would make little difference in performance.
Another thing that wasn't clear to me is where the "mode" behavior is handled...
What you asking about is 'Proportional–Integral–Derivative control feedback loop' (PID for short). This is a piece of software that monitors the state (motor encoder) and set point of each motor. If they are equals, the motor is stopped. If the set point is changed the PID software determines which direction to turn and runs the motor until the state equals the set point. More info can found at http://en.wikipedia.org/wiki/PID_controller.
The PIDs are in the NXT-G program and there is a large amount of I2C traffic in this version. Putting this PID loop into the firmware of the microchip processor would free up a lot of processing and I2C communicating power in the brick.
Mark_R80
Note that with all this shifting towards an on-board solution, it would become easier to have the board be "smarter" (handling things like a "go to this location" command autonomously, outside the brick), making the motors more responsive, sharply reducing the I2C load, and decreasing the processing load on the NXT as well.
Again, this looks like a really nice project - thanks for sharing!
I am using icommand. Can't we solve it by software? I mean can not we control mutliple NXTs from PC?
P.S. I am a kid.