Please reach out on Forum or Discord to get account approved. Manual approval required for all accounts due to hundreds of new account users daily from spambots.
<1> Define each pin as a variable. This makes it easy to change to another pin if you decide that is necessary.
.. annotations::
<2> Make other simple parameters variables. Again, this makes it easy to update them. When creating this test, I found that the PWM frequency to drive the motors needed to be relatively low to get over the kickback shown in :ref:`quickBot_motor_kickback`. I also found that I needed to get up to about 70 percent duty cycle for my circuit to reliably start the motors turning.
<1> Define each pin as a variable. This makes it easy to change to another pin if you decide that is necessary.
<3> Use a simple variable such as `state` to keep track of the test phase. This is used in a `switch` statement to jump to the code to configure for that test phase and updated after configuring for the current phase in order to select the next phase. Note that the next phase isn't entered until after a two-second delay, as specified in the call to `setTimeout()`.
<2> Make other simple parameters variables. Again, this makes it easy to update them. When creating this test, I found that the PWM frequency to drive the motors needed to be relatively low to get over the kickback shown in :ref:`quickBot_motor_kickback`. I also found that I needed to get up to about 70 percent duty cycle for my circuit to reliably start the motors turning.
<4> Perform the initial setup of all the pins.
<3> Use a simple variable such as `state` to keep track of the test phase. This is used in a `switch` statement to jump to the code to configure for that test phase and updated after configuring for the current phase in order to select the next phase. Note that the next phase isn't entered until after a two-second delay, as specified in the call to `setTimeout()`.
<5> The first time a PWM pin is used, it is configured with the update frequency. It is important to set this just once to the right frequency, because other PWM channels might use the same PWM controller, and attempts to reset the PWM frequency might fail. The <code>pinMode()</code> function doesn't have an argument for providing the update frequency, so use the <code>analogWrite()</code> function, instead. You can review using the PWM in :ref:`motors_servo`.
<4> Perform the initial setup of all the pins.
<6> `updateMotors()` is the test function for the motors and is defined after all the setup and initialization code. The code calls this function every two seconds using the `setTimeout()` JavaScript function. The first call is used to prime the loop.
<5> The first time a PWM pin is used, it is configured with the update frequency. It is important to set this just once to the right frequency, because other PWM channels might use the same PWM controller, and attempts to reset the PWM frequency might fail. The `pinMode()` function doesn't have an argument for providing the update frequency, so use the `analogWrite()` function, instead. You can review using the PWM in :ref:`motors_servo`.
<7> The call to `console.log()` was initially here to observe the state transitions in the debug console, but it was replaced with the `updateLEDs()` call. Using the `USER` LEDs makes it possible to note the state transitions without having visibility of the debug console. `updateLEDs()` is defined later.
<6> `updateMotors()` is the test function for the motors and is defined after all the setup and initialization code. The code calls this function every two seconds using the `setTimeout()` JavaScript function. The first call is used to prime the loop.
<8> The `M1_set()` and `M2_set()` functions are defined near the bottom and do the work of configuring the motor drivers into a particular state. They take a single argument of `speed`, as defined between `-1` (maximum reverse), `0` (stop), and `1` (maximum forward).
<7> The call to `console.log()` was initially here to observe the state transitions in the debug console, but it was replaced with the `updateLEDs()` call. Using the `USER` LEDs makes it possible to note the state transitions without having visibility of the debug console. `updateLEDs()` is defined later.
<9> Perform simple bounds checking to ensure that speed values are between `-1` and `1`.
<8> The `M1_set()` and `M2_set()` functions are defined near the bottom and do the work of configuring the motor drivers into a particular state. They take a single argument of `speed`, as defined between `-1` (maximum reverse), `0` (stop), and `1` (maximum forward).
<10> The `analogWrite()` call uses the absolute value of `speed`, making any negative numbers a positive magnitude.
<9> Perform simple bounds checking to ensure that speed values are between `-1` and `1`.
<10> The `analogWrite()` call uses the absolute value of `speed`, making any negative numbers a positive magnitude.
.. _quickBot_motor_kickback:
...
...
@@ -649,29 +651,31 @@ The `Fritzing custom PCB outline page <http://bit.ly/1xd1aGV>`_ describes how to
board outline. Although it is possible to use a drawing tool like `Inkscape <https://inkscape.org/en/>`_,
I chose to use `the SVG path command <http://bit.ly/1b2aZmn>`_ directly to create :ref:`capes_boardoutline_code`.
.. _capes_boardoutline_code:
Outline SVG for BeagleBone cape (beaglebone_cape_boardoutline.svg)
.. <dt><a class="co" id="callout_capes_bo_1_co" href="#co_capes_bo_1_co"><img src="callouts/1.png" alt="1"/></a></dt><dd><p>This is a standard SVG header. The width and height are set based on the BeagleBone outline provided in the Adafruit library.</p></dd>
.. <dt><a class="co" id="callout_capes_bo_2_co" href="#co_capes_bo_2_co"><img src="callouts/2.png" alt="2"/></a></dt><dd><p>Fritzing requires the element to be within a layer called <code>board</code>.</p></dd>
.. <dt><a class="co" id="callout_capes_bo_3_co" href="#co_capes_bo_3_co"><img src="callouts/3.png" alt="3"/></a></dt><dd><p>Fritzing requires the color to be <code>#338040</code> and the layer to be called <code>boardoutline</code>. The units end up being 1/90 of an inch. That is, take the numbers in the SVG code and divide by 90 to get the numbers from the System Reference Manual.</p></dd>
.. </dl>
.. ++++
.. callout::
.. code-block:: xml
:caption: Outline SVG for BeagleBone cape (beaglebone_cape_boardoutline.svg)
<path fill="#338040" id="boardoutline" d="M 22.5,0 l 0,56 L 72,56
q 5,0 5,5 l 0,53.5 q 0,5 -5,5 L 0,119.5 L 0,171 Q 0,193.5 22.5,193.5
l 238.5,0 c 24.85281,0 45,-20.14719 45,-45 L 306,45
C 306,20.14719 285.85281,0 261,0 z"/> <!-- <3> -->
</g>
</svg>
.. annotations::
<1> This is a standard SVG header. The width and height are set based on the BeagleBone outline provided in the Adafruit library.
<2> Fritzing requires the element to be within a layer called `board`
<3> Fritzing requires the color to be `#338040` and the layer to be called `boardoutline`. The units end up being 1/90 of an inch. That is, take the numbers in the SVG code and divide by 90 to get the numbers from the System Reference Manual.
The measurements are taken from the :ref:`beagleboneblack-mechanical` section of the :ref:`BeagleBone Black System Reference Manual <beagleboneblack-home>`, as shown in :ref:`capes_dimensions_fig`.
