WheelCommander^TM Motion Controller Frequently Asked Questions

General Questions

• Where can I buy it?
  Click here!
  
  
• 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 firmware upgrades.
  
  
• 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 wrong?
  
  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' flags?
  
  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 part numbers:
  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 larger.
  
  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.