Can anybody explain how to get startet with the “BeagleBone Motor Cape”?
Unfortunately there is no documentation. I searched the web for a day, but couldn’t find anything useful.
Do I need the I²C pins, or a re they only for recognizing the cape and it’s EEPROM?
Do the Mx.HIGH pins need to be connected/muxed to GPIO digital output mode to do the direction of the motors?
Do I need to connect/mux the Mx.PWMx.A/B pins to GPIO pwm mode to do the velocity of the motors?
In general:
I want to drive some DC motors.
What are the pins for?
Which pins are necessary and which are mandatory? (Do I need the dio/pwm pins or can I do everything via I²C like it seems to be with the “Adafruit 16-Channel 12-bit PWM/Servo Driver - I2C interface - PCA9685”?
How to configure to drive a DC motor (only how to configure via “config-pin” is known yet)?
Any help for me as a newbee (only adapted functions from comms cape at my custom cape in use yet) is welcome.
thanks for your quick reply and assistance. Before I dive into it, a few short questions to figure out my next journey.
the L298 driver requires a digital input for direction and a pwm signal, that is generated from a controller (in my case the BegleBone Black)?
the PCA9685 driver requires only a I²C bus connection from a controller (in my case the BegleBone Black), to do his own direction and pwm signal to drive the motor?
if I want to bring in additionally an encoder (optical incremental/quadrature) to get the position of the motor/driven elements, I probably should (or must) do all the stuff in the PRUs of the BeagleBone Black?
My goal is to use sensor signal for interrupt, then drive the dc motor from position x to position y (with slighty ramps at start and stop positions) and save the motor positions at the triggered sensor signal and finally save these motor positions in a file.
I am not 100% sure about the encoder work for your project. I mean to say this idea.
PRUs are a bit over my head as of now. I do not mess with the PRUs much. I know they can, at their highest frequency, handle 200MHz.
Outside of that idea, there is a book on the PRU online via github. The link is this one: PRU Cookbook .
It has tons of examples, working projects, and other ideas all revolving around the PRUs on the am335x SoC.
Now, if you would like, I can learn more about the PRUs but for now, I am outdated in this realm.
Seth
P.S. If you want to learn more about quadrature encoders, there are many ideas available online. With the correct sensor on a motor, I am sure figuring it out (if new to them) might take some time. But!
Those two guides may provide some insight but looking to books may prove more valuable. Oh! There is also a person, I think, named mattb0ne. That person was using the PRUs along with encoders (I think). Who knows? They may jump in here to give a more detailed description on what actually needs to take place for you to get up and running on these specifics.
thanks for the hints and links. Right away I’m familiar enough with encoders to undestand their function.
I haven’t tried to implement anything concrete yet. I wanted to find out first how I can solve the task before I end up a dead end
Right now it is not clear to me yet, if a control in positioning mode in user space works at all and can be fast enough in data acquisition (interrupt with sensor and storing the motor position). Or if I should do it better in the PRUs (which of course seems to be more complex, but would also save our already limited resources, because the PRUs run independently).
after decided to make small steps (and to keep on topic), I wanted to rotate a dc motor with linux shell commands only first.
For completenes I use the beagleboar.org official released distribution Debian Buster 10.3 (bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz) and Kernel 4.19 (linux-image-4.19.165-bone-rt-r59_1buster_armhf.deb).
Pin configuration as PWM:
non permanent: config-pin P9.14 pwm
or permanent by loading the device tree overlay “BB-PWM1-00A0.dtbo” (old syntax) or compiling the device tree source “BONE-PWM1.dts” (slight changes needed: &bone_pwmss_1 → &epwmss1, &bone_pwm_1 → &ehrpwm1) and loading the resulting device tree overlay “BONE-PWM1-dtbo” in /boot/uEnv.txt
Control PWM device:
set frequency of pwm echo 2000000 > /sys/class/pwm/pwmchip4/pwm0/period
set on time of pwm echo 1000000 > /sys/class/pwm/pwmchip4/pwm0/duty_cycle
enable of pwm output echo 1 > /sys/class/pwm/pwmchip4/pwm0/enable
That outputs a DC voltage of 1/2 the board voltage = 1,6 V with a frequency (via multimeter) of 500 Hz. So far so good.
But if Motor Cape is supplied with 24 V DC and Motor connected to Motor 1 terminal, only the red LED is on (signals the pwn is active) and no voltage at the motor terminal. Even when activated the M1.HIGH pin.
Q: What is the function of the Mx.HIGH pins on the cape? Direction or Enable/Disable? Are the needed high/low to get output from the driver stages?
Q: What frequency suits best for DC motors with the cape? Highest possible?
Next steps would be: Integration of the encoder (quadrature, incremental) and position control the motor, first in user space, second in PRUs and observing the performance / differences of it (timing of control and cpu load) of both implementations. Best fits in a new thread/post.
GPIO is direction. HIGH is GPIO. You need to power the Cape via a barrel jack too. So, even if you are using a 12v Lead Acid Battery, the BBB must be powered via the barrel jack for the Cape to function properly.
Seth
P.S. When the LED lights up on the Cape, that signifies that the PWM is working and adjusting, if sourced correctly, the frequency and duty cycle.
the BeagleBone Black is supplied with a 2 A power supply via barrel jack and the cape is supplied with a labratory power supply with currently 24 V and 3 A via the power terminal. The DC motor was previously driven with it from 2 V and 250 mA till 26 V and 1 A.
So no need for the direction input via GPIO. OK.
With and without it and with all possible frequencies (and half of that as duty_cycle), the voltage at the motor terminals, stand still at -0,7 V.
Q: Any ideas how to step forward or check things? Otherwise I have to dive into the function and implementation of the L298P H-bridge.
But it doesn’t solve the issue. Even w/o motors the outputs are still off at -0.7 V.
For testing purposes I used to do free wiring the pins from the pin headers of the BeagleBone Black to the pin headers of the Motor Cape. Now I tried to put on the cape, and the board won’t start anymore. If I unplug the cape the board starts. Absolute only the barrel from 5 V 2 A power is plugged.
If other people will jump in, good. If not, that is okay too. Take time out instead of rushing if possible. Organizing!
Anyway, outside of that bit of ideas, I will attach my MotorCape and BBB and see what happens. Oh!
There is a /boot/uEnv.txt file. It may be outdated but with BONE_BUSES and BBORG_ Capes, it works. Let me see where I can get the info. and relay it to you soon.
The PWM out of the BeagleBone Black is not a problem for me. Right now I’m familiar with the device tree overlays in general. But also in including/loading them via uEnv.txt or configure them myself via device tree source file (dts) first, “make” them, copy them to /lib/firmware and including/loading them in uEnv.txt.
It doesn’t matter if I did a pinmux via “config-pin” or via device tree overlay for P9.14 and then free wiring the cape, or a loading the complete device tree overlay (BBORG_MOTOR-00A0) and attach the cape fully on the BeagleBone Black.
In the first trials with pinmux only one pin and free wiring, everything looks quite good, beside the missing output at the motor terminal.
After the second trial with cape device tree overlay and attached cape, the BeagleBone Black won’t start anymore, if the VDD3V3 connection is pluged into the cape. Figured out with free wiring. It results seemingly in a shortcut, so the voltage drops to almost zero.
Q: Do you had been involved in the construction/engineering process of the cape?
Q: Can you assist me (e.g. how to measure at specific points) to justify a failure of the cape?
I was not involved in the construction of this Cape nor was I part of the process.
Wire the DC Motor to connector one in any way (only two ways).
Attach a quick disconnect or however you are attaching your battery.
Attach the battery.
Plug in the Micro USB to USB 2.0 from the BBB to your dev. desktop.
Use a power bank with 5v 2A to barrel jack and plug it in.
Run the source.
The motor should move.
Seth
P.S. The kicker is the Power to the barrel jack. The Cape will not work unless 5v is put to the barrel jack on the BBB. I am not sure if you understood this fact. It took me a while to understand it. I will keep attempting to help but it is three power connections, e.g. battery, Micro USB, and barrel jack for this MotorCape to function. Now, if you set up a .service file to run on boot, you can probably take away from real time programming and testing by subtracting the Micro USB cable to dev. desktop.
Oh! If you need some simple source, use the Adafruit_BBIO lib. that is available. It will be good for testing to see if everything is in working condition.
Oh and about that second question, yes. I can help. Plug in all three power supplies, attach your DMM to the connectors at PWR and GND and see if you read 12v or however many volts you are connecting.
You can also use the continuity test when supplying voltage to the BBB via barrel jack (I think). I will need to test this use case. I can. I will test it soon and reply.
the BeagleBone Black is supplied with a 2 A power supply via barrel jack and the cape is supplied with a labratory power supply with currently 24 V and 3 A via the power terminal. The DC motor was previously driven with it from 2 V and 250 mA till 26 V and 1 A.
For sure the power supply is done right. Either to the cape or to the board itself. From Ground up / my approach from beginning was as follows: board → cape attached to board (first attemps via free wiring) → power supply 24 V DV 3 A attached to the cape → barrel jack with 5 V DC attached to board → board booted → PWM configuration → but no output voltage on the cape and therefore no motor running.
Just to make things clear. I know about the issue to properly power the board (some say via power jack first, boot and then plug in usb) and the cape (ability to supply enough current). Isn’t
But from my understanding, a voltage should be measured at the motor terminal of the capes, even if no motor is connected there; or not?
It is currently too early to use / try out any libraries. First of all, the motor at the cape should run with PWM. For now on I can configure my PWM via linux shell commands. In the future I can dice into others ways.
Probably the cape is defect and I need a new one. The pins on the capes ic were correct at my first trials.
Q: At what frequency and Durty cycle did you run your motor. Does this play a role for DC motors or in which range should the values lie? (I have already written that I had already tried all possible values without result).
For a bit, there was something called Bone-Buses, too. So, setting the GPIO pin to HIGH/LOW may not work unless the dts is done correctly.
Seth
P.S. Let me go and check for the Bone-Buses idea for the MotorCape. Okay, I see an issue. If you are not on 4.19.x, the Cape dts is not available by BBB.io. You will have to write your own for kernels older than 4.19.x. If you are on 4.19.x, you can use their dts.
For completenes I use the beagleboar.org official released distribution Debian Buster 10.3 (bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz) and Kernel 4.19 (linux-image-4.19.165-bone-rt-r59_1buster_armhf.deb).
Therefore I can use the preinstalled “BBORG_MOTOR-00A2.dtbo” file or compile the “BBORG_MOTOR-00A2.dts” file from github and copy it to /lib/firmware and then loading it via uEnv.txt. Or I can do it as decribed with free wiring the cape and use only one PWM:
Pin configuration as PWM:
non permanent: config-pin P9.14 pwm
or permanent by loading the device tree overlay “BB-PWM1-00A0.dtbo” (old syntax) or compiling the device tree source “BONE-PWM1.dts” (slight changes needed: &bone_pwmss_1 → &epwmss1, &bone_pwm_1 → &ehrpwm1) and loading the resulting device tree overlay “BONE-PWM1-dtbo” in /boot/uEnv.txt
The PWM and even the GPIO is not a problem for me (anymore )
I wired the GND, VDD.3V3, SYS.5V, one PWM and one GPIO pin. Unsuccessfully for the output of the cape.
My only problem was (really) no output at the motor terminals; in the first place. Then with cape attached to the board, 3.3 V rail dropped, so no boot for the board is possible anymore. Now also the free wiring fails if 3.3 V connected.
My current conclusion is, that there is a failure in the cape, but I can’t figure it out (where and especially why). Can you find any fault in my steps of investigation?
Therefore I have buy and try another one… Sadly but still hopeful…
I already know about that there are newer builds around there, and thought about trying a newwer build or version in general. I downloaded the 10.8, 10.12 and 11.3, but not tested them yet. But in the end they are not officially released, so functionality is probably worse than the recommended 10.3 from beagleboard.org.
I know about the snapshot site and the balena Etcher. But thanks.
So lets go on logically. What do you think will change? The cape needs PWM (range of period and duty_cycle still unclear; but 500 Hz for right now), power supply (sufficient power supply capacity) and nothing more. If I want to change direction GPIO; already tried. Every requirement was fullfilled; isn’t it or still something missing?
What makes you think that it would work with a new version or what would be different then?
It would be more like groping in the dark.
From my point of view there is no imagination on how to crash the cape, so it would not output at the motor terminals and later do a shortcut for the 3.3 V rail…
Q: Perhaps the capes motor termials need a specific load and my motor is not the right one? Or shouldn’t I still see a voltage at about 2/3 of supply voltage at the motor terminals at all without a motor connected, for any reasons? (I tested w/ and w/o motor connected; but no output)
If all the discurs leads to a dead end, I have to dive into how double H-bridges are working. uuuaarrrggg (not willing to do so ;-))
the current exceeds 1,5 A during testing with only free wiring VDD.3V3 and GND. It seems to be an defect on my board.
The 5 V rails are OK.
Can you probably confirm/check that with your cape?
From the schematic of the cape, there shouldn’t be such a current consumption. Possible issues could be:
-any of the capacitors C2, C3, C4, C5 has a defect and does a shortcut from VCC to GND
-the EEPROM U1 has a defect and shortcuts VCC and GND
resisitor R8 has adefect and shortcuts VCC and GND
From a soldering point of view everything looks OK. Also the components on the cape looks OK. No optical issue can be detected.
I am not sure what to say now. I do have one here. I can test it again. I will update you at some point. I have a few other ideas on building Linux systems that I am currently trying to configure.
Seth
P.S. After a couple more tries and builds, I will attach the MotorCape and try my ole repo.
)