EasyC V4 - Do Motor Speeds Need to be Pre-Filtered?

VEX V5 General Discussion General Forum
#1

Its a simple question, with a simple answer I hope.
Does a variable, for example, int ‘motorspeed’, need to be filtered within the -127 to 127 range before using a motor output block?

Another way of asking it would be, what would happen if i set a motor to a speed of say 1000? Does the cortex change this to 127 on its own, or will this just not work?

It’s been a while since I’ve programmed, and I don’t have a cortex nearby to test my code. With only a few days later this week to debug my programming before we pack for competition, I’d like to get it near perfect before hand.

Thanks

#2

No, speeds are not pre-filtered. The GUI will not allow you to set a fixed speed outside the range +/- 127 but if you send a variable then it will give an error on the Terminal window such as

[FONT=“Lucida Console”]Setting Motor Speed with bad value 1000[/FONT]

or whatever speed you are trying to send.

#3

So in the latter case I assume the motor will not run, or the change in speed will not take effect, correct?

#4

Correct.

The easiest way to improve this if you are calling SetMotor is to create a small user function to replace the SetMotor call which will do the limiting.

For example

void
SetMotorWithLimit( unsigned char ucMotor, int iSpeed )
{
    int speed;

    speed = iSpeed;

    if( speed >   127 ) speed =  127;
    if( speed < (-127)) speed = -127;
        
    SetMotor( ucMotor, speed );
}
#5

Nicely done!

It’s a little cleaner than what I have written, but I’d have to integrate my motor inversions into it. I normally wait till the end of my program to invert motor directions to keep it simpler.
I’m out of time to clean my code; competition is in a few days. However, I’ll add it into my programming template for next year (if you don’t mind ;))

Thanks!

#6

Is this the same for RobotC? Will a motor not run at all if it’s being sent a value outside of the -127/+127 range?

#7

If I remember correctly, ROBOTC will limit for you, although I have to say that I encourage bounds checking as a matter of course.

#8

Quick question about programming:
In the past I have tried to write Proportional Integral loops without success. I can write both pieces fine, and they work on the robot. However, when i try to multiply them by non-integer gain values (K), i run into issues.

So right now I have a simple P loop. Basically it is:
Motor = (Setpoint-Sensor)

It works, but I wanted to tune it better. If I use this, all hell breaks loose:
Motor = (Setpoint-Sensor)/2

My motor variable is a long type, the setpoint an unsigned int, and the sensor a unsigned int.
Is this an issue concerning variable types? Or am I missing something?

Again, I’m using a Cortex with the latest version of EasyC v4 (sorry, i dont have the program here with me for the exact version number)

#9

Yes, and will be somewhat compiler dependent.

Take this code for example, I compile this on my Mac as follows.

cc test.c

#include <stdio.h>

void
BadFunc(unsigned int x, unsigned int y)
{
    long   err;
    
    err = (x - y);
    printf("err is %ld\n", err);

    err = (x - y) / 2;
    printf("err is %ld\n", err);
}

void
GoodFunc(unsigned int x, unsigned int y)
{
    long   err;
    
    err = (x - y);
    printf("err is %ld\n", err);

    err = ((int)x - (int)y) / 2;
    printf("err is %ld\n", err);
}

int
main(int argc, char *argv])
{
    printf("Bad function\n");
    BadFunc(20, 30);
	
    printf("Good function\n");
    GoodFunc(20, 30);

    return(0);
}

Same math as you are trying to use, two unsigned int’s and a long.

This is the output.

Bad function
err is -10
err is 2147483643
Good function
err is -10
err is -5

You can see the math for the line


    err = (x - y) / 2;

has given you a large positive result, probably the same problem you have.

So either use “int” for your variables or cast them to int for the math. Why did you make them unsigned?

#10

I wrote them as unsigned since i was using a potentiometer and that’s the variable type EasyC recommends. :rolleyes: So then any math that combines unsigned and signed variables (is that what they’re called?) may lead to issues?

Now that i think about it on the byte sized level that makes sense…pun intended

#11

You need to make sure that unsigned integer operations do not wrap. Google that and you will turn up plenty of programmers with your exact question, here is one result.

I’m not sure why EasyC would recommend unsigned int for sensors, the analog sensors such as a pot will return values in the range 0-1023 (or 0-4095 for the high res version), well within the range of a signed int. I normally use unsigned when, for example, I need a container for information where each bit has meaning or perhaps I plan to use shift operations.

For quad encoder counters I would use long as 16 bit ints may overflow.

#12

That probably saved me hours of guess-and-check debugging and a few sets of gears! It also explains why my motor variable was jumping so high on my feedback display.
Thanks jpearman!
Only a little more programming and tuning left, then I can pack it up and sleep easy for a few days until competition

#13