Raptor and MotorControllerL298

Just for a clarity of the experiment only bare minimum modules are connected to the Raptor. Following three tests were performed, using same code:


        void ProgramStarted()  {
            Debug.Print("Program Started");
            RunMotorsSampleA1(motorControllerL298);
        }

        public static void RunMotorsSampleA1(MotorControllerL298 motorBoard)    {
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor1, 100);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor1, 20);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor1, 0);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor1, -100);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor1, 0);
            Thread.Sleep(500);

            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, -1);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, -2);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, -5);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, -10);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, -20);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, -99);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, 0);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, 100);
            Thread.Sleep(500);
            motorBoard.MoveMotor(MotorControllerL298.Motor.Motor2, 0);
            Thread.Sleep(500);
        }

Case 1 – direct connect
[em]Raptor, UC_Battery_4xAA (socket #8), MotorControllerL298(socket #18), and Button (socket #10), 7.2V 2000mA external battery for motor controller[/em]

In debug mode – both motors rotate both directions (which is surprise to me) but only when speed is set to 100%, any other speed value stops a motor;
Standalone – exactly same behavior reproduced consistently including multiple reboots;

Case 2 – through the hub – S2 – H5
[em]Raptor, UC_Battery_4xAA (socket #8), HubAP5 ( socket #2), Tunes (socket H5), and Button (socket #10), 7.2V 2000mA external battery for motor controller[/em]

In debug mode – motor on socket J1 only turns in one direction when negative speed is set, any positive speed stops the motor. Motor on the J5, respond to any negative speed, but rotates at 100 percent rate; J5 motor will run in opposite direction too when positive 100% speed is applied.
Behaviors is the same as I had in the past few days with many other modules connected.
Standalone – both motors turn ONLY IN ONE (1) direction, and only when negative -100% speed is applied, any other numbers stop motors. Same consistent behavior on reboot (5 times rebooted).

Can you try speeds in the range of 50 - 100 and -50 - -100? Lower speeds do not always produce an output on the motors.

1 Like

I’d also be trying a longer run-time than 500msec, but that’s just me :whistle:

1 Like

I did a “for” loop to ramp up the speed from 10 to 100 and then from -10 to -100 with the 1000ms thread delay (will post the code later today)

Basically, results on the positive speed are the same as before - it is 100 or nothing…
The negative speed turns motors immediately, but it does not feel that speed is controlled, if it is it only very very slightly.


        void ProgramStarted()
        {
            RunMotorsSampleA1(motorControllerL298, MotorControllerL298.Motor.Motor1);
            RunMotorsSampleA1(motorControllerL298, MotorControllerL298.Motor.Motor2);
        }

        public void RunMotorsSampleA1(MotorControllerL298 motorBoard, MotorControllerL298.Motor motor)
        {
            for (int i = 10; i <= 100; i += 10)
            {
                motorBoard.MoveMotor(motor, i);
                Thread.Sleep(1000);
            }
            motorBoard.MoveMotor(motor, 0);
            Thread.Sleep(100);

            for (int i = -10; i >= -100; i -= 10)
            {
                motorBoard.MoveMotor(motor, i);
                Thread.Sleep(1000);
            }
            motorBoard.MoveMotor(motor, 0);
            Thread.Sleep(1000);
        }

Solved the problem… Finally.

In short: every motor is different, default driver frequency 50KHz did not work for my motors.

I have refactored MotorControllerL298 driver, expanded MoveMotor method to accept frequency in addition to the duty cycle and direction. Then used debugger to fine tune parameters, in my case I have found that my geared motors will work at frequencies up to 25KHz. Too low frequency and motor will be choppy, to high and it will simply turn on or off… The duty cycle scales are different for motors as well, one of them will react from 10 to 100% giving me fine well balanced control, others will not move until duty cycle gets to 70%.

Will work on it tomorrow and give you more updates.

Over all I can move forward with my project.

Thank you everybody for your help.

1 Like

Put a scope on the digital pwm signal, does its duty cycle vary linearly in proportion to the value you specify?

If not then that suggests a bug.

I have no idea how the board gens a pwm signal, does it use some dedicated pwm chip or some discrete logic?

I designed a discrete pwm circuit years ago, it misbehaved on the bench so i was able to run it on an emulator (made by Valid Logic Systems) and i found the issue, one or two specific values caused the duty cycle to act weird, it was caused by a propagation delay oversight with a bunch of TTL gates, easy to fix.

That design was pure hardware, took an 8bit input, FF = 5v continuously, 00 = 0v continuously, 7F = 50% duty cycle etc. The frequency was not selectable, that was down to some passive components.

If your pwm relies on software to go from output value to duty cycle, then a bug cannot be ruled out.

Like i say, put a scope on and observe duty cycle for every possible output value.

Not everyone has a scope.

In this case, the Raptor (and pretty much every mainboard I’m aware of) use on-processor hardware PWM to generate PWM. If there’s an issue it might be because of the setup of the hardware pwm port, but as you can see from this investigation it was related to the frequency used.