Hey there,

When I am using code like this:

The motors run really jerky and the bot shakes about a little, really annoying. However, when I turn like this

it's a smooth ride. The batteries are fine, they're as fresh as anything. Is there something I can tweak with the synch'd motors to make it run a little smoother?

I am using v1.30B4.

Regards,
Xander "full of questions" Soldaat.

I can copy that!
And I take the view, yet with 1.05 this hasn't been that distinctive

Thanks for testing the problem, Ford. Yeah, I hadn't noticed it at all with the 1.05 std and enhanced. At first I thought it was something with the motors or the batteries. I am glad it is neither but sad that it's the FW.

Where can we submit bugs for the beta?

Regards,
Xander

maybe here:
http://www.education.rec.ri.cmu.edu/too ... w_page.php
(first you have to register)

But till I'm 100% sure that it's a bug, I always am posting it here. The developers are supposed to read them all...

Did some more testing and you can reduce the jerkiness by changing the nPidUpdateInterval parameter.

The default value is apparently 25ms and that doesn't seem to be small enough. However, when you make it <= 15 it is a LOT smoother.

Regards,
Xander

Moreover, this motor controlling parameter seems to belong to another hidden background task.

I think in RobotC, there are much too many system parameters and background tasks - to crown it all, mostly undocumented.
And over and above that the compiler produces "code optimization" which sometimes is faulty and was not strictly necessary. (Let the programmers optimize their codes by themselves! It's their responsibilty!))

If a background task is needed, it's also the responsibility of the programmer, not of the compiler!

I agree to a degree. However, you must not forget the target audience of this product. It is used a lot in education and you can't expect a 12-15 year old to be able to do all those things (yet). I agree with the documentation part, though. I would love to know some of the more nitty gritty details of how the FW does certain things, like the PID control of the motors, for example.

In the end it's a trade-off, both for the manufacturer and the developer. Power and control vs ease of use I think RobotC does it quite well and I am quite happy with it so far. In fact the only "problem" I have now is that my robot reacts too quickly to certain events. It is something I didn't have to deal with when using NXC. I think it something I can live with, though

Regards,
Xander

I doubt if a 12-15 year old child needs those built-in system features like nPidUpdateInterval or nMotorPIDSpeedCtrl.

And I hope that you won't misunderstand me:

I wish RobotC to be easy to use, but in a straight and direct way, just like C with it's macros and libraries.
For example, in every C language there is the basic command and key word set,
and besides this, there are "basic expansions" like
- a stdio.h with a console for input and output,
- a math.h or math.lib with exp and sin and atan and tanh,
- as well as some "advanced, more complex libraries" like a sort library with a quicksort

all these are made to make programming easier. I really appreciate those expansions also at RobotC, above all, where C has got no definitions or interfaces (e.g., for motor or sensor control). But don't let a compiler use hidden function parameters or start hidden background tasks which cause sort of "own existences".

Above all, RobotC should be C - and not a language of "fantasy and imagination".

Just remember KISS: Keep It Simple and Stupid - as far as possible:
- and not in spite of, but just because of didactic reasons

I have to agree with Ford here.

I like compilers to make my programming life easier, but as an experienced programmer I NEED to know what's hapenning in the background.

The example of C libraries is great.

When a student that I'm mentoring asks "How does the robot do that?" it's important for me to answer inteligently and accurately. If I don't know the answer I need to be able to say "Let's go look at the library and find out".

If I just have to guess at what's hapenning, then I'm doing two things....

1) I'm potentially providing the student incorrect information.
2) I'm missing the opportunity to pass on the knowledge accumulated by the person who wrote the "hidden" library in the first place.

Just my 2c worth.