WheelCommanderTM Motion Controller Frequently Asked Questions
Design, Inc. All Rights Reserved. Nubotics, WheelWatcher and WheelCommander
are trademarks of Noetic Design, Inc.
- Where can I buy it?
- What do the LEDs mean?
The RED LED (DL1) will be lit after power
on reset to indicate that stored EEPROM values are being used; if off immediately
after power on reset, the red LED indicates that the Clear EEPROM jumper is active
(connecting pins 1 and 2 of JP1). If the Clear EEPROM jumper is active, the serial
port baud rate will be reset to 38400, and the I2C slave address will be reset
to 0x20. During operation, the red LED will be lit during active movement, and
off at the end of movement. Further, the red LED, together with the green LED,
will flash through various combinations during the calibration procedure
to indicate the current step number. Finally, the red and green LEDs alternately
blink during firmware updates, to indicate that an upgrade is in progress.
The GREEN LED (DL2) will be lit when the command
receiver is idle, and off while in the middle of receiving and parsing a command.
Further, it, together with the red LED, will reflect the current stage of the
calibration procedure, and will also alternately blink with the red LED during
- What kind of encoders will it work with?
The WC-132 WheelCommander, firmware rev level 28, is only compatible
with 128 pulse-per-wheel rotation encoders, which output the decoded quadrature
signals of CLK and DIR. Future firmware versions might support programmable encoder
resolutions as well as the use of raw quadrature (ChA, ChB) signals.
- Do I need to zero out my servos by adjusting their potentiometers?
No, you don't. You just need to make sure the potentiometer is relatively
close to the center so that full speed operation in both directions is possible.
The built-in calibration procedure will detect the exact pulse width needed to
prevent servo motion.
- If I command the WheelCommander via serial, what can I do with it's I2C
port (or vice versa)?
Currently (firmware version 28), the unused command interface is inactive
and inaccessible. Future firmware versions might provide a passthrough capability,
so that a serially commander WC-132 can communicate with I2C sensors and transfer
sensor data back to your master controller.
- I can't seem to get I2C commanding to work properly; the Sync command works,
but nothing else. What's wrong?
The WheelCommander I2C slave mode requires the I2C master (your controller)
to support clock-stretching by the slave (the WheelCommander). For many commands,
the WheelCommander must perform some processing between reception of a command
via an I2C master write transfer, and a subsequent I2C master read request. If
the WheelCommander receives a read request when it does not have data ready yet,
it will assert (hold low) the SCL line to signal to the master that data is not
ready. When data is ready, the WheelCommander will release SCL, allowing the transfer
to continue. This clock-stretching method is part of the Philips I2C standard.
It will be helpful to test and debug your I2C master code with other simpler
I2C devices, such as I2C serial EEPROMs, to make sure it works prior to using
it with the WheelCommander.
Further, many I2C master hardware implementations will require you to implement
certain time delays between operations. The Microchip PIC 18F series of controllers,
for example, require delays between issuing a STOP and any subsequent START, of
at least 4.7 microseconds (50 microseconds in SMBus environments). Shorter times
will result in unreliable behavior, including but not limited to bus hangs.
- I've been looking at the status word. Reads fine. However, bits 15 and
13 are always at 1. These specify the state of the two 'clk' lines. Should these
reflect the state of the LEDs on the WheelWatchers? As I turn each wheel, the
'Dir' bits follow the LEDs.
This is normal. The red LEDs are hooked to ChA -- in other words, a buffered
version of the signal detected by one of the photosensors.
The green LED, however, hooks to the decoded direction output of the LS7084 chip;
this is the same as the "State of x Wheel Dir Line" in the status word
(bits 12 and 14).
The "State of x Wheel Clk Line" (bits 13 and 15) reflects the value
of the clock output of the LS7084, not ChA -- so they are not the same. The clock
output of the LS7084 only pulses low for tens of microseconds upon detection of
an edge transition on either ChA or ChB, so you would be lucky indeed to see bits
13 or 15 go low. In hindsight, these bits are not very useful, except to confirm
that the WheelWatcher encoders are connected.
- After I enable PWM mode by setting constant 2 to 0x98, I see pulses on
the servo outputs still. Is there something I have missed?
The servo output pins are connected to the PWM output pins, so you will
see the same signal.
- I'm using the WheelCommander with an external H-bridge and PWM mode. When
I try to run the Calibrate command, it runs one motor 100% on, the other nearly
100% off, for 4 seconds; then turns both wheels off; and then nothing. What's
The Calibration Status command, when issued after the Calibrate command (as explained
on pages 24-25 in the manual), will indicate an error code which should help diagnose
the problem. In the situation you described, the problem is most likely that you
have swapped the encoder connectors or the motor connectors.
- When calibrating, should I insert a sizeable delay before reading an 'a'
result, or immediately accept an error result and poll the status word for calibrate
complete? If using a delay, what would be a suitable value.
Once calibration is initiated by writing the 'K' command, in I2C mode,
it will ignore its own address and not respond to read or write requests until
the calibration completes, either with or without error. When the WC-132 finally
does respond to your request, it will return either an 'a' or an 'n.' Then, you
can issue a 'Q' command. (In serial mode, it will output an 'a' character or an
'n' character when calibration is complete, after which you can issue a 'Q' command.)
One scheme for dealing with this, after writing the 'K' command, is to periodically
poll (say, every 100ms) the WC-132 until it responds to a read request, then obtain
the status. You could implement this inside your firmware by having it retry (STOP;
delay; START; issue address plus read bit) every 100mS until you receive an ACK.
- How long does calibration take?
It really depends on the motors or servos and how they respond, but normally
approximately one minute.
- I've got the system moving, but when I execute a Set Position to 100, then
a Go, I get the following: one motor turns continuously in the correct direction,
but does not stop; the other motor runs for 3 seconds in the correct direction
then stops, then reverses; after 3 seconds, it reverses again. Is it possible
that this is caused by incorrect direction or PWM signals?
It sounds like you have not tuned the PID loops. Tuning is very important,
especially for DC motor operation, as every "plant" (motor driver /
motor / gearbox / encoder) is different. We highly recommend using our WCWizard
to make this easier.
It sounds like the position loop constants (KpP, KiP, KdP) are too large, and
also probably the steering constants (KdpP, KdiP). If you can't use WCWizard,
then please follow pages 25-28 of the manual. This is a common procedure
needed for all kinds of closed-loop motion controllers, especially those used
in industrial applications (but of course, also robots). Tuning of PID loops is
a bit of an art, but if you follow the process as described in the manual you
should have a good chance of getting it to behave well.
- Can I use the "motion control active" flag to verify that the
Wheelcommander is busy/idle, or do I have to check the relevant '...in progress'
Status bit 5, "motion control active," is the master flag for all motion
types, and is TRUE whenever moving to a position, rotating to an angle, moving
at a specified velocity, or rotating at a specified rotation rate.
- The WheelWatcher cables that come with the WheelCommander are too short
for my application. How can I get longer ones?
If you are using the older WW-01 or WW-02, we can sell 6" or 8" cables to you. Please contact info at nubotics
dot com. Or, you can buy the precrimped wires for a variety of lengths, as well
as the connectors, at Digikey. Here are the
H2019-ND - 4pos 2mm dual row crimp sockets
H2022-ND - 8pos 2mm dual row crimp sockets
H3BBT-1010x-A8-ND (x" orange 28 gauge wire with precrimped socket terminals
on each end)
H3BBT-1010x-R8-ND (x" red...)
H3BBT-1010x-V8-ND (x" violet...)
H3BBT-1010x-B8-ND (x" black...)
Replace the 'x' with a number for the length in inches; for example, H3BBT-10106-B8-ND
is for a 6" black wire.
If you are using the new WW-11 or WW-12, we can provide the appropriate information upon request.
- I can't seem to code the ability of a command to delay until the present
command has stopped executing. I am reading the status word and checking the flags,
but I can't find a flag or set of flags that gives me this effect. Sequences work
if I introduce appropriate delays, but I don't want to use this approach. Reading
the status word seems to be fine. What am I doing wrong?
Which command is presently executing? Is it an Angle, Relative Angle, Position
or Delta Distance command? If so, then Motion Goal Reached, Status bit 4, will
be set when the motion concludes. However, if the position loop PID constants
are such that the unit either overshoots and oscillates over the goal, or, that
it never quite reaches the goal because of static friction (because KdiP is too
small), then it may take a long time or may never actually terminate. Of course,
too large of an integral constant will make a PID loop unstable as well.
Other constants that affects this are KdH (angle hysteresis), KpH (position hysteresis)
and KpvTh (position velocity threshold). KpH sets the maximum error in position
or angle allowed to declare Motion Goal Reached. Likewise, KpvTh sets the maximum
absolute velocity allowed to declare Motion Goal Reached. Using an H bridge in
PWM mode, we've noticed that these constants may need to be adjusted somewhat
Note that the Velocity or Rotation Rate commands will be declared Motion Goal
Reached when the required velocity or rotation rate is within some tolerance of
the goal (KvTh). If the velocity PID loop is not properly tuned, it may never
quite reach the goal due to static or dynamic friction. The KiV (velocity integral
gain) will ensure that such friction is overcome, though too large of a value
will make the loop unstable.
So, better tuning will ensure it reaches the goal in a timely manner. As a problem
solving tool, you can query the current position, velocity, rotation rate, and/or
angle, and display that to yourself to see how much error there is. You could
add your own acceptable limits on this, so that you can issue a Coast command
before moving on to the next motion.
- What is the difference between non-trapezoidal position control vs. trapezoidal control?
Non-trapezoidal control means that the WC-132 will attempt to reach the desired position as fast as possible. It does not try in any way to modify your goal position request. You will need to control the velocity yourself by issuing incrementally larger goal positions until the real desired goal is reached; the delta in position each time divided by the time between changes gives you your requested velocity.
Trapezoidal control, on the other hand, controls acceleration and velocity as it moves to a goal position. The trapezoidal control code feeds a series of goal positions which change by increments determined by the currently required acceleration and velocity. Note that the actual measured real-world velocity that your robot will travel will be what you request only if the position control loop (PID) is well tuned.
In general, you may want to use trapezoidal mode since this will do the position scheduling for you, saving a considerable amount of communications overhead between your controller and the WheelCommander. This will in turn ensure that all required processor bandwidth in the WheelCommander is available to process high encoder interrupt rate in addition to doing PID control (were you to use high resolution encoders).
When using trapezoidal mode, you will need to issue a non-zero acceleration amount. Values on the order of the requested velocity (or a small integer multiple or fraction of it) work well under most circumstances. Acceleration values much larger than the requested velocity can expose a known bug in the trapezoidal control code.
- I will be using the Nubotics WheelCommander WC-132 to control 12 Volt DC encoder motors with external H-Bridges. The power source for the motors is a 12Volt lead acid battery. When the battery discharges, its voltage will drop, and a 100% PWM at low charge may result in a lesser voltage to motors than a 100% PWM at full charge. Hence, do I need to supply a constant regulated 12V to the H-Bridges (for powering motors) so that the wheel commander works effectively and is immune to voltage drop due to discharging of the battery?
You only need to do this if you must operate the robot at maximum velocity regardless of battery state.
Normally, you should set the maximum commanded velocity that your control program ever issues to the WC-132 to a value that works well all the way to the lowest safe discharge level of the battery (for lead acid, this is usually 10.8 volts) and under the worst expected conditions regarding friction and slope of ground. This way, regardless of battery level, the maximum required PWM is kept below 100%. If instead you were to set the maximum commanded velocity to the maximum speed the robot can run at when the battery is full -- which requires 100% PWM -- then indeed, there is little the WC-132 can do to get the robot to stay at maximum speed when the battery is low. In that case, speed as well as steering will not be well controlled.
Another reason to set the maximum commanded velocity below the maximum the robot can attain on a full battery is that it provides margin to allow the PID control loops to adjust for changes in friction, slope of the ground, and so forth, as well as to ensure there is adequate margin for steering.
- Or should I not bother about this issue and connect the h-bridges directly to the battery without a 12V regulator?
There is no need for a regulator normally. Also, it can be difficult to find such a regulator that can provide enough current for the motors and yet not be either costly or run hot. If you use a linear regulator, you would need the battery to always be more than 12v -- the amount more depends on the voltage drop of the regulator. Or, you could use a switching boost regulator, but they are expensive and complex.
This is based on the assertion that the control loops in the WheelCommander are taking feedback from the encoders and therefore will make all the required corrections even as the battery voltage drops over time?
As long as the commanded velocity does not require more than 100% PWM, then yes, the WC-132 control loops will adjust the PWM to maintain speed. This ability to correct for battery level changes often requires the I term (integral) to be non-zero.
- Can the Nubotics WheelCommander be used to drive a robot at an arbitrary speed set during runtime, or only at one particular speed that's pre-configured as per the PID constants?
The speed as well as rate of rotation can be commanded (modified) on the fly at run time. That is one of its main purposes.
The PID constants adjust how the feedback provided by the encoders, together with the commanded speeds of each wheel, result in motor control signals that seek to minimize the error between the feedback and the commands. They do not, by themselves, set the speeds of the wheels.
There may be some confusion due to the MxSpd constant. It stored in EEPROM like the PID constants are, is determined automatically by the calibration routine, and is later used to convert PID equation outputs to PWM values appropriate for your robot. It is not meant to be changed at run time.
- Are internal pullups enabled for the encoder input pins?
No, they are not. The encoder inputs need to be driven high and low by your encoder within the DC Input High and Low ranges mentioned in the Specifications section.