The ShieldIf you are interested in Arduino robotics, animatronics or powered RC vehicles, you have probably run across the "Fundumoto" motor shield from Keyes. It's incredibly attractive for smaller builds of such things as it combines an L298 h-bridge motor driver, which many motor shields would have two of, with sensor headers for the rest of the unused pins, meaning ma of what you get from a typical sensor shield, at a cost in line with those shields. Since the facilities are perfectly adequate for those small builds, it allows you to do them with half the shields, lower cost, space, weight and power consumption. All good stuff!
But first, a shout out to fluxworkshop on ebay. Their description said to contact them with any questions. So I did. They answered promptly with the information I needed, and politely thanked me for pointing out the problems in their description. If you want to order one of these, get it from them.
The featuresOk, let's look at what you get with this board. The most obvious feature is the big L298 chip in the middle. That's the h-bridge used to drive motors, and is the heart of the shield. It's also the weakest point of the shield, and it's going to get an extended discussion of it's own.
The peripheralsThere are two sets of screw terminals on the board. Those connect not to Arduino pins, but the L298. The two on the upper left is power input for your motors, the four on the left are the motor outputs, two for each motor. The second set are duplicated on a 4-pin header adjacent to them. The rest of the connectors on the shield are for Arduino pins, and will be discussed in the next section.
To either side of of the output terminals are a pair of LEDs. Each motor has one that lights up for each direction the motor can spin. While cute, they aren't all that useful because you can reverse the direction of a motor by swapping the terminals it's connected to, which won't change which LED is on. For the record, if the direction GPIO is low, the green LED is on, and if the direction GPIO is high, the yellow LED is off. Further, the duty cycles control the brightness of whichever LED is on.
Near the top of the board is a buzzer. It's connected to pin D4, and you can use it for - well, whatever you might want to do with a buzzer. Nice if you need it, but it feels more like a "because we can" addition than something really useful.
On the far side, near a big 12-pin header, is a red power LED. This is an important feature, as motor shields normally have two power inputs: the motors get their own, and the logic on the board can use either that one or the Arduino. It's possible to have one working and the other not, which can lead to wondering why your servos work but your motors don't! If this LED isn't on, your motors aren't getting power, even if your other devices are.
Speaking of dual power systems, the jumper in the bottom center of the board controls the connection between them. If it's off, the two power systems are separated. You'll need two power sources, one plugged into your Arduino, and one plugged into the two screw terminals on the upper left. If it's installed, then you only need one. The shield will provide power to the Arduino, so you don't need to power it. Or you can use DC power (not USB!) from the Arduino to provide power for both systems.
Finally, near the bottom left the reset button has been brought out as a convenience feature.
The pinsNow let's go over all those connectors for Arduino pins, in pin order.
We start on the right with a 12-pin header labelled bluetooth, and a 4-pin header labelled BT2. Both of those connect to pins D0 and D1, as well as power and ground. The big one is a legacy bluetooth connector that is apparently still used in automobiles, and the one above it is the "bluetooth stick"/"bluesmurf"/etc. bluetooth to serial adapter. You can just plug the stick in directly, and it connects to the hardware serial port. If you developed your project using the USB serial connections, you can move that over to bluetooth and just keep going. Really useful if you're using a bluetooth radio for remote control.
Below and left of these is a blue 3-pin header, again in the ground/power/signal layout. The signal here is D2, a convenient digital input.
Above the bluetooth connectors is another blue connector. From right to left, this is D3, GND (D4 is connected to the buzzer), D5, D6 and VCC. This puts the three PWM signals on the D0-D7 header on one convenient header. The pins are even adjacent to the labels for the pins they connect to, making it easy to find the one you need.
Adjacent to that is a yellow connector labelled "Ping". This connector is for rangefinder sensors that use an echo ("ping") to determine distance. From left to right, that's ground, the Trigger is conned to D7, the Return to D8, and finally VCC.
Near the motor power input is a white servo connector for the PWM signal on D9.
Last, in the lower right is a set of 3 rows of 6 pins, one each in white, red and black. Or turned on it's side, that's a row of 6 3-pin connectors, each being a 3-pin sensor connector with signal (white), power (red) and ground (black). These are the analog pins, ready to connect to and measure voltage levels.
Most of these connectors are things one would find on a motor or sensor shield. The BT2 connector is unusual, though I've got a proto shield with that connector on it. The legacy bluetooth connector is even stranger. Finally, I have no idea if the 5-pin blue connector matches some kind of sensor or device. If you know of one, please let me know. In any case, it's nice to have all the unused PWM ouputs in one place.
About the only thing missing is a general purpose comms port of some kind, either I2C or a serial port, as modern sensors have gone to those protocols rather than bit-banging things. The BT2 connector could pass for one of those, but has VCC and ground swapped compared to what's on a sensor shield. Not the fault of the shield, it's what the bluetooth serial devices use.
If I could change one thing about this shield, it would be merging the blue PWM connector with the servo connector to create a row of servo headers for the PWM pins not used by the motor. Even if I had to turn the A pin headers into a single row with shared power and ground to get it, it'd still be worth it for me. It is a hard call - some robots need lots of sensors, but I think more than one servo is more likely.
The h-bridgeAs previously stated, the h-bridge provided by the L298 is the heart of the shield. It's connected to the rest of the digital pins: D10, D11, D12 and D13. The two PWM pins connect to the enable functions for the two motors, and act as speed controls via the PWM duty cycle, D10 for Motor A, and D11 for Motor B. The corresponding GPIO - D12 for Motor A and D13 for motor B - are connected to each motors two input controls, once directly and once through an inverter, and thus act as direction controls: the motor spins one direction when it's high, the other when it's low, and stops - by coasting - when the speed is zero.
If you're confused by the GPIO pin for each motor being connected to two inputs, let's delve into the h-bridge a bit.
H-bridge theoryThe L298 has 2 h-bridges, one per motor. They're identical, so we'll just consider one of them.
An h-bridge is four switches that control the flow of electricity through the motor. Four switches implies four control lines, but many of the possible states are uninteresting, duplicating other states - you really only need one "off" - or to interesting, resulting in sparks and smoke and ordering replacement parts, so you can get by with 3 inputs, which the L298 datasheet calls EN, IN1 and IN2.
There's also two outputs - OUT1 and OUT2 - that are connected to the screw terminals. The h-bridge can route current between the two outputs in either direction depending on the two inputs. Those two directions drive the motor in the two different directions, and you get them by putting the two inputs in opposite states. So the shield connects the direction signal directly to one input, and through an inverter to the other input, resulting in the motor changing direction depending on the signal.
You might be asking yourself why the L298 doesn't do this inversion internally. It's a good question, and the answer is that the two states you can't get to in this configuration - where the two inputs are equal - are different from the two we can get to, and interesting. While the externally visible current flow is the same, the internal flow isn't straight through in this case, but loops through the motor, resulting in a situation known as dynamic braking. With the inverter, to stop the motor you set EN to 0, current stops flowing, and the motor slows down as friction drains the energy from it. With dynamic braking, the motor is also spending energy to generate electricity, which can lead to it stopping a lot faster.
Even more interesting, if you send the PWM signal to one of the two IN pins instead of the EN pin, then instead of alternating between running and coasting - aka run/coast mode, the motor will alternate between running and dynamic braking, or run/brake mode. Run/brake is a little bit harder on the electronics, but results in cleaner power usage and a speed curve that's closer to linear than run/coast. I look into that a bit in the review section below.
That was just a quick overview of a really deep subject. There are more in depth tutorials available if you're interested.
Missing h-bridge featuresSo this simple shield design can't do any braking modes. Not generally a problem for small devices, as the wheels won't have a lot of energy so their advantages are relatively minor.
You can control a unidirectional motor with each output of an h-bridge by wiring the motors to the output and ground. This board can't control them independently, so that it not having a terminal for ground isn't much of an issue. Stepper motor control is also problematic. While it can do it, it's not as straightforward as having direct connections to the inputs, so finding a library for that might be difficult.
Reviewing it in useI put this on a Nucleo-F411RE board. That board only has a USB power connector, and gets unhappy if you draw to much power from it. The fundumoto did so, even without trying to provide motor power. However, setting the Nucleo and fundumoto up so power for both came from the batteries worked fine, which is my intended use mode anyway.
The VCC pins on the shield were all connected to the 5V output of the Nucleo, which made using 5V electronics simple. However, since the Nucleo is a 3.3V system, inputs from the shield needed to be connected to 5V tolerant pins. Fortunately, that's everything except ADC inputs, so this is works well for me.
The chassis was a plastic tank, with a pair of 6V motors with 3-9V operating range. The L298 generates provides about 75% of the input voltage to each motor at max output, falling to about 20% - and to little to drive the motors - before the PWM duty cycle hit 50%. Applying a correction in the controls - basically, it goes from 0 at center to plus or minus 50 with any motion - compensates for this nicely.
This should be compared to using DRV8835 motor drivers which support all the h-bridge behaviors. It behaves the same way as an L298 in run/coast mode. But if I used run/brake mode, it could start from a stop with a 20% duty cycle, and would run with a duty cycle of less than 10%, though not start from a standing stop. Again, perfectly fine for some builds, but problematical if you need fine control, or for builds with larger motors.
The buzzer turns out to be an obnoxious high-pitched beep. It would work nicely for a "backing up" beeper on a truck.
I tied the battery output - through a suitable voltage divider - to one of the analog inputs, and fed that back to the control app to get telemetry. I connected the lights up to a couple of other A inputs, as using PWM for them seemed like overkill. Having connectors with power and ground immediately available is a huge win compared to using the Arduino headers. And having the pins on the board, rather than on stackable headers, meant that the connectors were just barely a little taller than they would have been using Arduino headers, and much shorter than they would have been using stackable headers on a pure motor shield.
I connected a turret - purchased just for the purpose - to the servo connector, and it worked very well. Again, the low profile compared to a prototype board is an advantage.
SummaryAs I said initially, the L298 is the heart of the shield, and it's weakest point. The various connectors are both useful and flexible enough that you can easily work around any that are missing. Further, the shield is available with stacking headers should you really want a wider selection of connectors.
Not having a ground terminal can also be worked around, though I still consider it a problem. But the missing braking modes? As of this writing, if you need them, you need a different shield.
In spite of all that, with proper documentation it's a good shield available at a good price - at least if it'll do what you need. Again, fluxworks was a big help with this, so I recommend buying from them if you need one. But avoid vendors who list the drive pins as D4-D7, as they clearly either don't know what they are doing, or aren't paying attention.