Demo Mode for Qik

Hello.

I am using the Qik 2s9v1 coupled with some micro metal gearmodes. I am currently running demo mode to check the capabilities of my motors and I am having some difficulties. According to demo mode, the motors are supposed to go up to full speed. My motors seem to be moving fairly slowly and turning back and forth only at a 10 degree angle. I tried two different batteries and the pwm measured on my oscilloscope is 6 V and 8 V, for my two different power sources. Is it possible that the gears need to be lubricated? Also, one motor is barely going backwards.

Thanks, again, in advanced.

Emily

Hello.

Can you be more specific about the motors you have? Are they from Pololu? What are their gear ratios (and are they HP)? Are they new? If you swap motors, does the issue of the barely turning motor stay with the motor or the port? When you say they turn at a 10 degree angle, do you mean that the shaft only rotates through 10 degrees during the few seconds the motor is being driven?

Can you tell me about how you’re powering everything (including the qik)?

- Ben

Hello Ben,

I am using these motors:
pololu.com/catalog/product/992

They are brand new, ordered a week ago. When I say that there is only 10 degree movement, I mean that the motors only rotate the wheels 10 degrees. My two different power sources are a standard 9V battery and pololu.com/catalog/product/1007. The qik is being powered by a basic stamp development board (so standard 5 V). I’ve verified all the power sources by my oscilloscope.

I have the 9 V hooked up to Vmot. the 5 V is hooked up to Vcc. I toggle reset in the beginning. Motors move, but barely at all.

Thanks,

Emily

Also, the LEDs from the Qik are doing their normal pattern for demo mode.

You shouldn’t use a 9V battery for applications that require a lot of current, like driving motors. I’d recommend using AA or AAA alkaline or NiMH cells.

Do the motors act differently if you connect them directly to power? Without the motors connected, does the output of the qik’s motor drivers look right on your oscilloscope (it should be a PWM output with the duty cycle increasing and then decreasing over time)?

- Ben

Thanks Ben.

To answer your question, the pwm for both motors remained constant (this was with the 6V 700mA battery). I tried running motor one at full speed and noticed it did a lot of starting and stalling. A closer looked showed my that M1’s signal was a constant 6V. I checked with my oscilloscope and my javelin stamp is sending the correct serial code. Do you think I should replace my current battery with some that your recommended.

Here is my code:

import stamp.core.*;

public class TestQik {

  static Uart tx = new Uart(Uart.dirTransmit, CPU.pin1, Uart.dontInvert, Uart.speed9600, Uart.stop8);
  static Uart rx = new Uart(Uart.dirReceive, CPU.pin0, Uart.dontInvert, Uart.speed9600, Uart.stop8);


 public static void main(){


    int i = 0;

    tx.sendByte(0xAA);
    tx.sendByte(0x09);
    while (i == 0){
    tx.sendByte(0x0D);
    tx.sendByte(0x7F);

    }

 }


}

Just to clarify I did get proper pwm for demo (although no decreasing or increasing). Running the code showed no pwm, just 6 V

Hey Ben! You were right. It was a power failure. Thx again.

I’m very glad to hear it; that’s so much easier of a problem to solve than bad motors! Good luck with your project. I’d love to hear more about it as it progresses if you feel like sharing.

I was looking at your code:

int i = 0;
tx.sendByte(0xAA);
tx.sendByte(0x09);
while (i == 0){
tx.sendByte(0x0D);
tx.sendByte(0x7F);
}

And I’m a little confused as to why you put the last two serial transmissions inside an infinite while loop. It should suffice to do either:

// pololu protocol
tx.sendByte(0xAA);
tx.sendByte(0x09);
tx.sendByte(0x0D); // M1 forward
tx.sendByte(0x7F); // full speed
while (1); // loop forever (the qik will keep running the motor)

or

//compact protocol
tx.sendByte(0xAA); // you only have to send this once so the qik can learn the baud rate
tx.sendByte(0x8D); // M1 forward
tx.sendByte(0x7F); // full speed
while (1); // loop forever (the qik will keep running the motor)

Repeatedly sending { 0x0D, 0x7F } won’t do anything since the qik ignores data bytes (i.e. bytes < 128) that aren’t associated with a command packet.

- Ben

hmm. I did these changes but have not noticed any pwm. M1’s signal is constant 6 Volts. It is rotating pretty well now that i’m using proper batteries.

The code in my (and your) example drives the motor at full speed (100% duty cycle), so it just looks like a constant voltage at your power supply voltage. You have to set it to a speed below 127 to see the PWM.

- Ben

Hello Ben,

I went ahead and varied the speed through the full range of motion and it worked completely. My one remaining problem is that I am not getting any feedback from my qik. I have the qik connected to my javelin. The qik’s logical pwr is powered by the javelin’s development board. I’m using a fully charged battery for my Vmot. My code is to check the firmware version. But I am not receiving any feedback both on my oscilloscope and in my terminal.

code:

import stamp.core.*;

public class TestQik {

  static Uart tx = new Uart(Uart.dirTransmit, CPU.pin4, Uart.dontInvert, Uart.speed9600, Uart.stop1);
  static Uart rx = new Uart(Uart.dirReceive, CPU.pin3, Uart.dontInvert, Uart.speed9600, Uart.stop1);


 public static void main(){
     
//get firmware version
    CPU.delay(100);
    tx.sendByte(0xAA);
    tx.sendByte(0x09);
    tx.sendByte(0x01);
   
    if (rx.byteAvailable()){
      System.out.println(rx.receiveByte());
    }
 }
}

How are you powering the qik’s logic? Do the qik and Javelin share a common ground? I’d like you to try the following (all using the compact protocol since it’s simpler):

  1. Reset the qik and then send it 0xAA so it can learn the baud. You should see the green LED change from an even blink to a brief, periodic flash.

  2. Send the command 0x82. You should see the green LED briefly turn on (an indication of serial activity).

  3. Send the command 0xBB. You should see the red LED turn on and stay on (an indication of an error, since the command 0xBB doesn’t exist).

  4. Send the command 0x82 again. You should see the green LED briefly turn on and the red LED turn off.

If possible, send these commands sequentially so you can observe the effects of each one individually. Make sure that you see the LEDs behave as I’ve described.

When you send 0x82 in step 2, the qik should transmit back 0. When you send 0x82 in step 4, the qik should transmit back 0x40. If the qik is otherwise behaving as expected but you aren’t receiving these transmitted bytes, the problem is either with your code or your qik TX signal connection, or the TX pin on the qik has been damaged/burned out. I’m concerned that you aren’t seeing anything on your oscilloscope, but I’m hoping it is because you are not using it correctly.

When you are doing the above tests, can you connect the oscilloscope directly to the qik’s TX output (and leave your javelin disconnected from the TX pin for now)? If you don’t see any data on the TX line with the oscilloscope, can you connect it to the RX line and see if it picks up the data your Javelin is sending to the qik (i.e. verify that you are indeed using the scope correctly)?

Lastly, looking at your code, I notice one potential problem. Does the function rx.byteAvailable() block for a certain amount of time while waiting for a byte to be received? Given the lack of a timeout parameter, I’m guessing that it does not, which would at least explain why your Javelin isn’t receiving anything. You potentially reach that “if” statement while your Javelin is still in the middle of transmitting the last byte of the command packet. You need to wait for the Javelin to finish transmitting this byte (assuming the tx.sendByte() function doesn’t block during the send), and then you need to wait for the amount of time it takes the qik to transmit its response byte. What happens if you try inserting a a CPU.delay(50) between the final send and the check for a received byte?

- Ben

Hello Ben,

Thanks again. The delay command was the culprit. For the most part my motors and qik are fully functional. I was able to control the motors fully and get proper feedback. One motor is definitely a little weaker than the other and I plan to investigate this more tomorrow. Thanks.

Emily

I’m glad to hear you have it working. Note that the 50 ms delay I suggested was rather excessive, so feel free to decrease it to something more reasonable. In general, I’d expect there to be a read-byte function that takes a timeout value as an argument, or you could build serial byte-polling into your main loop so it doesn’t have to sit around doing nothing while waiting for data from the qik.

As far as one motor being weaker than the other, that’s not necessarily strange. No two motors are exactly the same, which is why a lot of people use feedback systems on their robots to ensure that they drive where they’re supposed to (such as in a straight line). It would be a cause for alarm if one motor is substantially weaker than the other, but slight differences should be expected. If you don’t have encoders or some other feedback system, you can still try to empirically calibrate your system by finding out what power difference causes the motors to spin at the same speed and using this power difference in your control code.

- Ben