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?
  
  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.
  
  
• 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.