I’m starting this thread to post the results of the evaluation of ROBOTC V4.xx (currently V4.05) that I hope to do over the next several days. I’ve had a bit of a poke around in the new version and the jury is still out on whether it’s a useful upgrade when used with the cortex. I’m not going to be looking at the VEX IQ implementation here, that will be the subject of another post in a couple of weeks.
I’m afraid, as usual, figuring out the new functionality is a bit of a scavenger hunt. I see some exciting new functions available in the function library, but no documentation on how to use them or what they do. This first post is a bit lightweight but this is what I see so far.
[ATTACH]7818[/ATTACH]
shiftOut(dataPin, clockPin, bBitOrderLSBFirst, nValue, nDelay);
This has actually been around for a while although I’m not sure if it worked before. This allows serial data to be clocked out using the digital IO pins on the cortex. The pins both need to be set as digital outputs, use is something like this.
shiftOut( dgtl1, dgtl2, true, 0x55, 10);
The delay seems to be some type of loop variable and does not correspond to uS or anything else that makes sense. This function has been tested and does work.
shiftIn(dataPin, clockPin, bBitOrderLSBFirst, nValue, nDelay);
This should be a companion function to the above but I’m unable to get it to work. The received data, which seems to use the old style ROBOTC syntax of passing a variable by reference, rather than the more standard C way of passing a pointer, always contains the value 255 no matter what I do to the data input pin.
What would have been nice would have been a “shiftOutIn” function that did both at the same time, this would have allowed sensors with an SPI interface to be used in VEXU, although I suspect the underlying code is just bit banging so not very efficient.
[ATTACH]7817[/ATTACH]
sendI2CMsg(sendMsg, nReplySize);
readI2CReply(replyBytes, nBytesToRead);
These looked promising, figured that we had access to the I2C port for sensors other than the IMEs, alas, they don’t work. I should really say that I’ve been unable to make them work, despite having some clue as to what I’m doing. Even getting them to compile was a struggle as the way they are defined is again “old style” with the sendMsg (whatever that is, does it contain an address? A message length? ) apparently wanting a constant.
bUseVexI2CEncoderVelocity
I assume, but have not confirmed, that this uses velocity data coming from the IMEs in perhaps the PID calculations. It should be a boolean but currently want’s an integer assigned, presumably “1”.
[ATTACH]7819[/ATTACH]
mtrPid_Period]
mtrPid_Deadband]
mtrPid_kD]
mtrPid_kI]
mtrPid_kP];
Read/write variables to access and change some of the PID control parameters, use in the same way as the motor] variable.
mtrPid_ErrorD]
mtrPid_ErrorI]
mtrPid_ErrorP]
mtrPid_StartEncoder]
Read only variables related to the PID control.
motorPWMLevel];
Another read only variable that was in the RobotCIntrinsics file but not shown in the function library. This gives the actual pwm values being sent to the motor when under PID control.
moveMotorTarget(nMotor, nEncoderCountTarget, nMaxSpeedToUse, bHoldAtEnd);
setMotorTarget(nMotor, nEncoderCountTarget, nMaxSpeedToUse, bHoldAtEnd);
These function allow positional control of the motor, one is absolute, the other relative. They could be used to drive to a position or control an arm/lift system.
getMotorTargetCompleted(nMotor);
A function to determine if the above positional control has finished.
waitUntilMotorStop(nMotorIndex)
A macro using the above function, it implements this.
do{
sleep(100);
while(!getMotorTargetCompleted(nMotorIndex))
sleep(1);
} while(false)
slaveMotor(nSlaveMotor, nMasterMotor);
This allows a non-encoded motor to be slaved to an encoded motor, I did not try this yet.
getMotorSlewSpeed(nMotor);
The PID code implements slew control (somewhat, more on this in another post), this function allows you to get the rate of change per period, unfortunately there is no function to set rate of change per period, only the motors and sensors dialog.
getEncoderAndTimeStamp(nMotor, nEncoder, nTimeStamp);
getEncoderForMotor(nMotorIndex);
getMotorEncoder(nMotor);
mapEncoderToMotor(nMotorIndex, nSensorIndex);
resetMotorEncoder(nMotor);
Various encoder related function most of which I did not try yet.
I will talk about the PID control in another post, however, suffice to say at this point there are a couple of serious drawbacks. The most significant is that it does not allow responsive manual control, that is, when trying to control motors during the driver control period it makes it really hard to control the robot. The second drawback is that there is no way (that I can find) to turn PID off or on in code, if you configure motors to use it you are stuck using it throughout the program.
I went back and took a look at the 3.61 beta from last year, it has some more PID functionality that has been removed in this version. These variables have now gone, I don’t know why because they were useful.
mtrPid_PowerLimit]
mtrPid_SlewUp]
mtrPid_SlewDown]
mtrPid_PowerSlew]
[ATTACH]7820[/ATTACH]
I didn’t dig into any of these yet, looks like they are something to do with simplified standard control of a clawbot or something like that (they are intrinsics unlike the natural language stuff).
That’s it for this post, next time I will look at the PID setup menus.
