Hello,
I am trying to get the pre-assembled Zumo kit (the one that is the shield) working with a micro:bit and the microdriver breakout board. I am having difficulty getting the motors to move. I am wondering if anyone could help. Here are a few questions.
Thank you for your help.
~Mr.R^2
Hello, Mr.R^2.
I moved your post to the robots support section of our forum since that seems more appropriate.
I do not know what else you are hoping to do with your Zumo, but for driving the motors you should not need a micro:Driver expansion board. Since the Zumo shield has a built-in DRV8835 dual motor driver all you should need to do (aside from making sure both the Zumo and your micro:bit are powered properly) is connect appropriate logic pins on your micro:bit to the shield’s DIR and PWM pins, which are on digital pins 7-10 per the “Features and components” section of the user’s guide, and send appropriate signals.
The DRV8835 has a logic voltage range of 2V to 7V, so the 3…3V signals from your micro:bit should be fine. I do not know what the default PWM frequency is if you use micro:bit `write_analog() commands, but I suspect that the frequency will be within the DRV8835’s range (250kHz max).
I am not sure what you mean by the “duty of the motor controller”, could you explain that? If you have not already, you might also try using the product page for our DRV8835 carrier or the DRV8835 datasheet as a reference to find more information about the driver.
- Patrick
Hello,
Thank you for your response.
I am fully aware that perhaps this is not the best model of the Zumo for our particular situation. Truth be told, we purchased this on a bit of a whim to go with our Romis.
The DFRobot device is nice because in addition to providing the motor and servo outputs, it also acts as a breakout board for the Micro: Bit. At the moment, we are just attempting to drive the Zumo (with the eventual intent of creating a practice bot for students to learn to code with it). I have been writing micro:bit libraries for the team that utilizes the FRC framework in order to teach them to code. I liked this kit, because it was pre-assembled and had a better gyro than the Micro:bit, but if I am having this much difficulty with motors, I am thinking the I2C may be a bit difficult.
I have poured over the documentation, the Zumo manual, schematics, and the DV8835 documents as well, but am only understanding it partially proficiently. As you may realize (you have helped me previously :), I am learning some of the lower-level aspects of programming and robot construction this year as we are experimenting with mini-robots. This is the latest iteration.
When I say Duty, it is because the libraries I am familiar with use both a duty cycle (perhaps 1-2.4 ms and a frequency, but often, I find the datasheets only use one or the other.
When I get no movement out of the H-bridge, my first thought is either one or both of those variables are wrong. However, there seems to be a lot more going on here.
I first tried the DF Robot Servo ports (which run a 600-2400us Duty cycle @50hz) combined with the Digital ports that were broken out of the Micro:bit. I got no motion and was thinking that it was either that wrong timing, or a power issue.
I have since realized my issue was I was only testing one motor. When working with both, it seems that it does not matter which of the four pins I use as the phase pins, if any of the four pins are set to 0 (or not set at all, even if pulled hi), neither motors move. If I set any two pins to 1, and write any analog value to the other two pins other than 0, the motors move. around 255, they stop, but it is not consistent. if both analog levels are too low, the motors stall (even if the treads are off the ground). if the difference between the left and writeanalog() value is large, the speed increases in opposite directions, if they are the same but above 255, they both go fast in reverse. I have yet to figure out how to get them both to go fast forward.
Once I figured that out, I could go back to the servo ports.
Anyway, this behavior does not sound like the datasheet described either mode should be. I am using pins 7-10 just as the user guide suggests, but as I said above, it seems as though it does not matter which pins I use, the behavior is the same.
Although I do not have a compatible Arduino, I do have an Arduino Nano and wired it up as recommended, then ran the Zumo Motor Sketch. It moved the treads independently, but only in one direction for each (backward).
I looked at the wiring diagram, and I think I may have a theory. In both of my wirings, I left the 5v pin untouched. Is the mode button of the motor driver hard-wired to the 5volt bus, or the arduino 5volt pin? if it is the latter, that may explain the behavior.
Thank you for your help.
The Zumo shield does not have an on-board 5V or 3.3V regulator; it depends on those voltages being supplied from the Arduino. You will need to supply power to those pins for components like the motor driver to work. For your application with the micro:bit it should be fine to supply both pins with 3.3V.
By the way, whenever you mentioned duty cycle in your last post, it seems like you were actually talking about pulse width. To clarify, pulse width is the amount of time a square wave signal is high, e.g. 1500 ÎĽs pulse width. Servo electronics will generally measure pulse widths to determine target position; signals used for this are generally called hobby servo signals. Duty cycle is the percentage of time a square wave signal spends being high, e.g. 50% duty cycle. Changing the duty cycle of a signal applied to a motor will change the motor speed; signals used for this are usually called PWM signals. Since pulse width and duty cycle are both aspects of a square wave, these properties are related, but it is generally not good to call a PWM signal a hobby servo signal or vice versa because you emphasize the importance of the wrong property. For operating the DRV8835 driver on the Zumo shield, what duty cycle you apply is most relevant since that will be translated to how power is applied to the motor.
- Patrick
Hello,
Thank you. That is helpful and makes a lot of sense. I did notice that discrepancy but got confused about the nuance between the two. The info about the power is extremely helpful and definitely seems to be the culprit of the odd behavior I am experiencing. I will try that and let you all know how things pan out in case anyone else comes searching.
~Mr. R^2
Edt: Yep. That was the issue. Things are now working as expected. Thank you for your help. I still think it would have been better to choose just the chassis, motors, and encoder for this project. In the future, that is definitely the route we will take, but for now, we are all set. Thank you for your help.
