I am trying to ramp up the power to two synchronized motors so a dual differential robot will accelerate in a straight line.

Putting two motor statements inside a for loop and increasing the power each time it goes through the loop appears to cause the PID algorithm to reset every time it goes through the loop, just like it does in NXT-G, resulting in a robot that goes anything but straight.

In LabVIEW with the NXT-G firmware, you can simply set the Power to the power level you want to achieve, set RunState to RUN_STATE_RAMPUP and set the TachoLimit to the distance you over which you want the ramp up to occur. This results in a very accurate acceleration of both motors.

I've tried doing something similar in ROBOTC using nMotorRunState, but as indicated in ROBOTCHelp, nMotorRunState only appears capable of reading the run state, rather than being able to change it. The Built-In Variables Help suggests that nMotorPIDSpeedCtrl is able to be set to "dual sync motor", but I haven't been able to figure out exactly how such a command is supposed to be written or whether or not it would help if I were able to do that.

Is there some way to ramp up the motors without losing the PID synchronization in ROBOTC?

Kurt,

The devs are working on built-in support for ramping up and down of motors but it does not work with the sync'd motors yet. I have a short video of it here: http://www.youtube.com/watch?v=B8YIsW3cBTc

As for the manual ramping and resetting of the PID algorithm, that's a bug (or a very odd feature at least). I would recommend you submit a ticket to support@robotc.net. Some simple example code will probably help them.

Regards,
Xander

Before I submit this as a support ticket, I just thought I'd share the program to make sure I'm not missing something obvious.



As you can see from the screenshot of the NXT Sensor and Motor Display below, motorB travels almost 100 degrees farther than motorC.

What happens if you don't use the SyncedMotors feature and instead just set both motors to the same power level in your loop? This should help identify whether you have found a bug in the SyncedMotors feature or whether it is something else.

cu,
Gary

I don't consider this a bug. Rather, it is just what I would expect to happen from this program.

MotorC is synched to motorB. Therefore, I assume the firmware is using the power set by the motor command as the power to be applied to motorB and using the PID algorithm to determine the power to be applied to motorC. As the power to motorB is increased, the PID algorithm keeps increasing the power to motorC in order to get motorC to the same speed as motorB. Because of the lag in the PID algorithm and the fact that the power to motorB is steadily being increased, motorC is always running slower than motorB during the ramp up.

To answer Gary's question, the motors accelerate more evenly if they are not synched. Doing it that way only results in the motors being about 30 degrees different. Attached is the code doing that.

Hm, interesting. Maybe you could try braking at the end using:

//* Use tight control of the motor speed
nMotorPIDSpeedCtrl[TheData.MotorNumber] = mtrSpeedReg;
bFloatDuringInactiveMotorPWM = false; //* brake

I haven't found any comprehensive documentation on how all of this works, have you?

cu,
Gary

As I stumble into and rediscover everything you '*cough*senior*cough*' folks have already found many years ago, I came across this. I just recreated your experiment, and it does not appear to ever have been finished. Perhaps that is why it is not in the documentation

So looking for suggestions as to which road to follow. Is it possible to implement myself?
I think other 'environments' have done so and the code is available, but I haven't looked in detail lately. would my code in robotc be quick enough? not how the code style itself is written, I know that's my problem, but does user code run as fast as the firmware code that tries to implement this function, or is it native instructions and I could never get as close?

I have often implemented something like this using a simple linear "curve", ie a fixed rate of acceleration until the desired speed is reached with a minimum and a maximum, of course. I will see about digging up some code where I did this, but I can't guarantee I still have it.
The built-in acceleration would've been nice if it had actually been finished properly and not left hanging.
Just had a look and if you go into the "drivers" folder in my suite, there should be a file called "FLAC-ramp-driver.h" there. I believe it was some of the acceleration stuff in there. It doesn't work very reliably with the Linear Actuators I had intended it for but the code should be fine, once you rip out all the task-related stuff.

- Xander

Thanks. I will check it out.