There should be no need to integrate the gyro. The virtual sensor (is supposed to) emulates the RobotC gyro driver and returns 10ths of a degree (not a value proportional to the angular rate, like the raw reading would be). Hopefully that should solve most of the issues reported in Routines 1 and 3. I will look into the drifting problem.

If you can post your code for Routine 2, I can see if I can reproduce the problem.

With the new version, the user is given a choice of either the IR Sensor or the gyro. Our (physical) robot uses both an IRSensor and a Gyro (to give accurate turns), so we are unable to emulate this in Virtual Worlds.

Would it be possible to get a version that contains both the sensor and a gyro. In my mind, the light sensor isn't very useful, but I'm sure others would disagree.

Nate

Tue Nov 13, 2012 10:34 pm

nateww

Rookie

Joined: Fri Apr 15, 2011 10:29 amPosts: 37

Re: Ring It Up Gripper bot has no arm encoder

rcahoon wrote:

There should be no need to integrate the gyro. The virtual sensor (is supposed to) emulates the RobotC gyro driver and returns 10ths of a degree (not a value proportional to the angular rate, like the raw reading would be). Hopefully that should solve most of the issues reported in Routines 1 and 3. I will look into the drifting problem.

If you can post your code for Routine 2, I can see if I can reproduce the problem.

I'm not aware of which RobotC driver you are referencing. All of the code I've seen uses Xander's 3rd party code to access the HiTechnic Gyro, which requires iteration of the gyro. If there is coe which returns the robot's heading, it would be great to have a pointer to said code...

Okay, here is the scoop. I have fully debugged my code so it is working perfectly now. Here is what I found that I need to fix/work around in order to make my code work again.

1. Previously there was no "Hitechnic Gyro" sensor type and Xander's code was using "I2C Custom" that gave you the raw turn rate, so I had to write a gyro module that integrates the turn rate into heading. So it seems by declaring the gyro with the new "Hitechnic Gyro" sensor type, SensorValue will integrate the turn rate for you. Am I understanding this correctly? I am talking about the physical gyro sensor in the real world, not necessarily the virtual gyro sensor in the virtual world. With this new sensor type, is there a way to get the turn rate then? In some application such as the Segway, one may use the turn rate of the gyro instead of the heading. I assume you can still declare it as I2C Custom type and get the raw turn rate if I need to, correct? I tried declaring I2C Custom type in the Virtual World but it seems it's still integrating the heading. Is it true? My wish: please document the behavior of SensorValue() and SensorRaw() with each of the sensor types.

2. The gyro heading starts out with -17350. Not really a big deal but I was expecting it would be initialized to 0.

3. I have calibrated the wheel encoders and found it to be 0.00564 inches per encoder click. Am I correct? My wish: when publishing a sample robot in the Virtual World, you may want to also publish the characteristic of the robot such as inches/click for the wheels or at least numbers such as encoder with 1440 clicks per revolution, gear ratio 16:24, wheel diameter 4-inch etc so one can derive the inches/click. For the gripper bot, the arm motor encoder resolution (1440/rev), arm length so one can use trigonometry to calculate the arm angle to arm height conversion (for PID control purpose). I suppose we could do it empirically too but it is an opportunity to teach the students some math.

4. I discovered the virtual world encoders do not respect the "reversed" settings in the motor pragma. This forces me to negate the left wheel encoder value before using it. That's why the PID control did not stop because I was averaging the left and right encoder values to get the "distance travelled". But since the left encoder was negative, it canceled out the right encoder value making it seems not moving at all. In my opinion, this needs to be fixed.

BTW, I use this code to train students to program in RobotC using our FTC library. This is the solution code that demonstrates timed drive (dead reckoning) versus PID control drive. If you want to take a look, you can access it from here.http://proj.titanrobotics.net/hg/Ftc/20 ... s/Solution

Wed Nov 14, 2012 4:40 am

jbflot

Site Admin

Joined: Tue May 15, 2007 9:02 amPosts: 409

Re: Ring It Up Gripper bot has no arm encoder

Quote:

1. Previously there was no "Hitechnic Gyro" sensor type...

There was, but it didn't show up in the Sensor Debug window or Motors and Sensor Setup unless you were in Expert mode or above. We changed it to show up in Basic mode in the latest update. It does not provide the rate, so a more advanced driver would be needed for that.

Quote:

2. The gyro heading starts out with -17350. Not really a big deal but I was expecting it would be initialized to 0.

It does start at 0 on my computer, at least on the first run. Have you updated to ROBOTC 3.54?

Quote:

3. I have calibrated the wheel encoders and found it to be 0.00564 inches per encoder click. Am I correct? My wish: when publishing a sample robot in the Virtual World, you may want to also publish the characteristic of the robot such as inches/click for the wheels

Your calculations line up with mine. Thanks for the suggestion. We considered this, but we were already experiencing information overload with just saying the inputs and outputs on the GUI. Perhaps we should note it in sample code at least.

Quote:

4. I discovered the virtual world encoders do not respect the "reversed" settings in the motor pragma.

Would it be possible to get a version that contains both the sensor and a gyro. In my mind, the light sensor isn't very useful, but I'm sure others would disagree.

Thanks for the feedback. This is the trouble that we're running into - due to the limitations of the number of sensors supported by the NXT, any set of configurations will be short of what some teams are hoping for.

One of our future updates is to allow the robot to be configured however you want it to, with the sensors that we currently support. This particular update is part of a bigger endeavor, so it will be some time before it's included.

I tried declaring I2C Custom type in the Virtual World but it seems it's still integrating the heading. Is it true? My wish: please document the behavior of SensorValue() and SensorRaw() with each of the sensor types.

Currently, the virtual world injects sensor values directly into the RobotC program without regards to the sensor type. This is something we can look into changing for a future release, but probably won't be changed right away.

MHTS wrote:

2. The gyro heading starts out with -17350. Not really a big deal but I was expecting it would be initialized to 0.

In the current release, the gyro won't reset between program runs. I will fix this for the next release, but a simple fix for now is adding a line such as the following to the top of your program:

Code:

SensorValue[gyro] = 0;

MHTS wrote:

3. I have calibrated the wheel encoders and found it to be 0.00564 inches per encoder click. Am I correct? My wish: when publishing a sample robot in the Virtual World, you may want to also publish the characteristic of the robot such as inches/click for the wheels or at least numbers such as encoder with 1440 clicks per revolution, gear ratio 16:24, wheel diameter 4-inch etc so one can derive the inches/click.

EDIT: I should note that currently, the encoders are set to measure the output rotation of each wheel/joint rather than the motor rotation, as they should for Tetrix. The only place where this should make a difference is on the shoulder/arm joint of the Gripperbot. I will fix this in the next release.

MHTS wrote:

For the gripper bot, the arm motor encoder resolution (1440/rev), arm length so one can use trigonometry to calculate the arm angle to arm height conversion (for PID control purpose). I suppose we could do it empirically too but it is an opportunity to teach the students some math.

It seems reasonable that we could publish a PDF of dimensioned drawings for each robot. This is something we can look into including with future releases.

There was, but it didn't show up in the Sensor Debug window or Motors and Sensor Setup unless you were in Expert mode or above. We changed it to show up in Basic mode in the latest update. It does not provide the rate, so a more advanced driver would be needed for that.

But if I use I2C Custom type, I will still get the turn rate for _Target_Robot but not for Virtual World, right? By the way, would you tell me the difference between SensorValue and SensorRaw for the gyro in both _Target_Robot_ and the Virtual World and for the sensor types I2C Custom and Hitechnic Gyro?

jbflot wrote:

It does start at 0 on my computer, at least on the first run. Have you updated to ROBOTC 3.54?

I am using 3.55.1. In any case, knowing it doesn't reset the gyro between runs, it might have been a left over value from some erroneous runs. Will exiting RobotC and restarting it clear the gyro reading? I suppose I can just add the code to zero the SensorValue as Ryan suggested.

jbflot wrote:

Your calculations line up with mine. Thanks for the suggestion. We considered this, but we were already experiencing information overload with just saying the inputs and outputs on the GUI. Perhaps we should note it in sample code at least.

I have determined the 0.00564 number empirically by driving the robot in a straight line for 10 ft and noted the average of the left and right encoder readings.

rcahoon wrote:

It seems reasonable that we could publish a PDF of dimensioned drawings for each robot. This is something we can look into including with future releases.

That would be great. Essentially it will be the technical specification of the robot.

Wed Nov 14, 2012 3:23 pm

MHTS

Guru

Joined: Sun Nov 15, 2009 5:46 amPosts: 1523

Re: Ring It Up Gripper bot has no arm encoder

Is it true that in real robot world, the gyro doesn't integrate even if you declare the sensor type being HiTechnic Gyro? I tried that tonight on a physical robot with a real gyro sensor and the gyro doesn't work at all unless I go back to my old code that does the integration.

In the Virtual World, the gyro is returning heading in the unit of 1/10th of a degree by just reading SensorValue[gyroSensor], not the turn rate. I am wondering if you can do the same in the real world robot. I tried it last night and it doesn't work. If that's really true, that's not good because then the program for the Virtual World doesn't work in the real world robot. That defeats my purpose of using the Virtual World to test some code for the real world robot.

Thu Nov 15, 2012 1:32 pm

rcahoon

Site Admin

Joined: Tue Oct 09, 2012 10:34 amPosts: 192

Re: Ring It Up Gripper bot has no arm encoder

MHTS wrote:

Is it true that in real robot world, the gyro doesn't integrate even if you declare the sensor type being HiTechnic Gyro? I tried that tonight on a physical robot with a real gyro sensor and the gyro doesn't work at all unless I go back to my old code that does the integration.

It does look like that's the case (apparently, integration happens with the Vex sensor but not with the HiTechnic sensor). My best suggestion is to use compile-time flags to select which code to run based on the target. In your RobotC installation folder, check Includes\NatLangInclude.c because it looks like the flag has changed in the last version. The conditions are either:

Code:

#if (_TARGET == "VirtWorld")#elif (_TARGET == "Robot")#endif

-or-

Code:

#if defined(_Target_VirtWorld_)#elif defined(_Target_Robot_)#endif

If you're trying to run the same code on both the virtual and real robots, chances are your program will require different parameter values for movements, timing, etc anyway. As I said, in the future, we may be able to return different values depending on the set sensor type (could be useful in multiple places, for example sensorSONAR_cm vs sensorSONAR_inch in Vex), but this won't happen at least for a while.

It does look like that's the case (apparently, integration happens with the Vex sensor but not with the HiTechnic sensor). My best suggestion is to use compile-time flags to select which code to run based on the target.

Okay, good to know. I already modified my code to condition compile with different configurations. In any case, just want to raise the issue so other people don't try to make the virtual robot code work in their real robot.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum