Advice about USB polling

[*++argv]

Using the Interface Kit 8/8/8 and a magnetic sensor:

Trying to assess the rough position of the system, and take action if the position is beyond a given value. Doing something like this (simplified)

Code: Select all

int speed = 50;
set_velocity(MOTOR, speed); // Acceleration is 100

while (get_hall_value() < 700) { // CPhidgetInterfaceKit_getSensorValue()
   usleep(1000); // 1 ms
}

speed = -speed; // Reverse speed
set_velocity(MOTOR, speed);
...


Basically, let the robot go on as long as it doesn't reach a given distance from a magnet.
When it does, it reverses the speed and go back a few centimeters (then stop).

This works fine as long as the speed is <= 50.

Above 50 (intended speed is above 80 actually), there is a delay between the position detection (hall value >= 700) and the reaction (reverse speed). Meaning the robot goes a few centimeters farther than expected (No inertia issue, since for the prototype we use very light devices).

• Checked manually, reversing speed is visually instant
• Did Hall sensor tests in another program: here again the position detection is visually instant (ie the value returned by the CPhidgetInterfaceKit_getSensorValue() function has no delay, even when called thousands of times a second)

So I wonder why the delay occurs:

• Is mixing two Phidgets USB devices in the same program add some delay (threading Hall processing would help?)
• Is polling the Hall sensor USB so many times (every ms) gives a buffering/delay? Meaning the polling is asynchronous?
• In this case what would be a solution to this problem?

Thank you

[*++argv]

Tracing with time (ms) the events, I can see that the motor is going farther for about 50ms.

And 50ms... is the time it takes to transmit the "Reverse polarity" order to the controller, via USB. Am I right?

That means the only reason there is a delay is because the USB orders transmission is too slow.

Is there a way to refine this? To get the motor react more quickly to an event?

Thanks

[Patrick]

50ms is a long time. Transmitting a command to the controller over USB should take very little time - probably 1ms depending on your PC. There can be a delay of 8-16ms on the sensor values. I would suggest setting the data rate to 1ms on your hall effect input, and the change trigger to 1, and then using the sensor change event and controlling the motor from within that event for minimum latency.

Also, the acceleration set on the motor controller will affect how quickly it can change direction. You mention that your acceleration is 100, which would mean that it takes 1 second to change from 100% velocity to 0% velocity. You could try setting a much larger acceleration. I'm not sure what controller you're using, but 1065 can go from full forward to full reverse in 32ms, 1064 in 100ms. I wonder if you're using the 1064 and running into the 50ms time to go from 100% to 0% at max acceleration?

If you just want to stop the motor as quickly as possible, you could also set enabled to false, then set the velocity to 0 then set enabled to true.

-Patrick

[*++argv]

Thanks Patrick, great remarks.

Actually using the 1064...
I purchased the 1064 because it was more expensive ...thinking it had to be better!
But the price difference is actually due to the number of motors, I presume.

I almost changed completely the system topology, while it seems it could be a matter of settings.

Did the following

1) So, on the 1064, working on max acceleration.
Was using

Code: Select all

CPhidgetMotorControl_getAccelerationMax()

to get the max acceleration (gives 100.0) then fed into setAcceleration() ...

Tried other values:
<100 : acceleration decreases, as expected
But setting an acceleration value > 100 produces an actual acceleration less (or equal) to what we had at 100...

Is there any magic value to boost the acceleration, better than 100?

(and tried to reverse the speed, 100 to -100 or -100 to 100, to amplify the acceleration effect (instead of stopping the motor))

2) Sensor:
setDataRate(phid, MOTOR, 1) is now set (the change trigger was already set to 1, and there isn't much visible change)