Is it good practice to mix natural language commands in with your program that uses ROBOTC commands? Or is it best practice to replace the natural language commands with their equivalent?
motor[port1] = 127;
delay(3000)
motor[port1] = 0;
while(true)
{
tankControl(Ch1, Ch4);
}Mixed code like the following code seems like an obvious mistake to avoid. (will ROBOTC allow it?)
motor[port1] = 127;
setMotor(port8, -32);
No errors with ROBOTC. It might look a little weird so I would probably avoid it personally but the example of tankControl would probably be fine looking anyway.
It seems like every time I sit down I use a different wait command but that isn’t that much of an issue.
wait(100);
sleep(100):
delay(100);
wait10mSec(100);
Natural language is implemented by using a header file, so when you use
setMotorSpeed( port1, 50 );
There is a macro that expands it that looks like this.
#define setMotorSpeed(motorPort, speedValue) motor[motorPort] = speedValue
You can mix natural language and native ROBOTC language. It a matter of style and opinion as to whether this is good practice.
RobotC doesn’t care. You can hand it all kinds of mismashed nonsense and it sorts it out.
I somewhat care. If I’m teaching people how to program a robot then I want to make sure they understand how the robot works and the interaction of the joysticks and sensors with the motors. So I might have in a loop the read joystick values and set the motors. When we get to programming functions I would then put those commands into a function so it’s easier to understand. When we get to sensors then I could put the “if about to hit the wall then stop code” in that function.
Maybe for year three roboteers I’d say they could replace the hand code with the RobotC functions.
Key point is YOU or your programmer needs to know what the code does. When I come over to help you need to be able to say “tankcontrol is how it does tank drive” and understand what it does behind the scenes.
BUT, remember the natural language framework assumes where the motors are. If you move a motor, you can move it in regular code, but not in the natural language version.
I agree with this point entirely. The jump from Natural Language to ROBOTC can be a gradual transition from NL to ROBOTC (one method I’ve found that works is breaking down a Natural Language command into its ROBOTC equivalent code), a straight upgrade to the new code (I typically won’t recommend this method, as it tends to be very jarring for new programmers), or by skipping the Natural Language library entirely and starting off with ROBOTC code.
At the end of the day, it will all come down to the students and what they are comfortable with. If they have prior experience with programmer, or can pick up the concepts quickly and easily, they may be able to start out with the ROBOTC programming. If they are newer or younger, it may be wiser to start them with the Graphical Natural Language (same commands, just in a graphical format) or text-based Natural Language, and transition in from there.
We have a handy document that briefly shows this transition pathway and how the Graphical, text-based Natural Language, and text-based ROBOTC commands are related to one another; I highly recommend taking a look at it.
cough**cough (and by cough**cough I mean we have added drivetrain support to the Motors and Sensors setup, so you can designate a motor for the left or right side drive of your robot; this allows the Natural Language movements commands (such as a forward() command) to work properly with a custom robot configuration).
(and by cough**cough I mean we have added drivetrain support to the Motors and Sensors setup, so you can designate a motor for the left or right side drive of your robot; this allows the Natural Language movements commands (such as a forward() command) to work properly with a custom robot configuration).
pat pat There, there John, it will be OK. This is a case of “Umm, I don’t use that” so I never look at the upgrades in part of the notes. But now that I know I can tell roboteers “so you are doing it wrong, but if you are going to continue to do it wrong at least use the Motor and Sensor setup” :rolleyes:
Maybe I should dig around in the sofa to see if I can come up with the upgrade money…
Its up to you, RobotC wont complain, but some would argue it is not very good programming practice. I personally don’t mind and I think as long as you don’t have OCFD (Obsessive code formatting disorder) its fine.