View unanswered posts | View active topics It is currently Tue Jul 29, 2014 6:46 am






Reply to topic  [ 30 posts ]  Go to page Previous  1, 2
Ring It Up Gripper bot has no arm encoder 
Author Message
Site Admin
Site Admin
User avatar

Joined: Tue Oct 09, 2012 10:34 am
Posts: 192
Post Re: Ring It Up Gripper bot has no arm encoder
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.

_________________
Ryan Cahoon
CMU Robotics Academy
RVW Software Developer

Robot Potato Head; Virtual NXT


Tue Nov 13, 2012 8:40 pm
Profile
Rookie

Joined: Fri Apr 15, 2011 10:29 am
Posts: 37
Post Re: Ring It Up Gripper bot has no arm encoder
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
Profile
Rookie

Joined: Fri Apr 15, 2011 10:29 am
Posts: 37
Post 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...


Nate


Tue Nov 13, 2012 10:36 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:44 am
Posts: 439
Location: Pittsburgh, PA
Post Re: Ring It Up Gripper bot has no arm encoder
MHTS wrote:
Oh, I forgot about that link. I was downloading it at:
http://www.robotc.net/ftc/
If that's a formal release, you may want to update the link at http://www.robotc.net/ftc/


Thanks for pointing that out. It's updated that now.

_________________
Vu Nguyen
Software Training Development Team | Webmaster
Need more support? Use the ROBOTC Ticketing system

Robotc.net| Robomatter Store | Robotics Academy | CS2N


Wed Nov 14, 2012 12:14 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Ring It Up Gripper bot has no arm encoder
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
Profile
Site Admin
Site Admin

Joined: Tue May 15, 2007 9:02 am
Posts: 403
Post 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.


We'll look into this one, thanks.

_________________
Jesse Flot
CMU Robotics Academy
ROBOTC Support


Wed Nov 14, 2012 10:49 am
Profile
Site Admin
Site Admin

Joined: Tue May 15, 2007 9:02 am
Posts: 403
Post Re: Ring It Up Gripper bot has no arm encoder
Quote:
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.

_________________
Jesse Flot
CMU Robotics Academy
ROBOTC Support


Wed Nov 14, 2012 10:52 am
Profile
Site Admin
Site Admin
User avatar

Joined: Tue Oct 09, 2012 10:34 am
Posts: 192
Post Re: Ring It Up Gripper bot has no arm encoder
MHTS wrote:
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.


The wheel radius is published on the menu screen as 3.5cm. The encoder resolution is given as 1440 clicks / revolution at http://www.education.rec.ri.cmu.edu/previews/robot_c_products/teaching_rc_tetrix_preview/tetrix_sensing/documents/TETRIXSensing_printable.pdf#page=12. This gives me:

3.5 cm * (1 in / 2.54 cm) * (2 * pi / 1 revolution) * (1 revolution / 1440 encoder clicks) = 0.00601 inches / encoder 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.

_________________
Ryan Cahoon
CMU Robotics Academy
RVW Software Developer

Robot Potato Head; Virtual NXT


Wed Nov 14, 2012 11:38 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Ring It Up Gripper bot has no arm encoder
jbflot wrote:
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.

Putting the info in the sample code works. Thanks.


Wed Nov 14, 2012 3:04 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Ring It Up Gripper bot has no arm encoder
rcahoon wrote:
3.5 cm * (1 in / 2.54 cm) * (2 * pi / 1 revolution) * (1 revolution / 1440 encoder clicks) = 0.00601 inches / encoder click

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
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post 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.


Thu Nov 15, 2012 3:36 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3164
Location: Rotterdam, The Netherlands
Post Re: Ring It Up Gripper bot has no arm encoder
The HT Gyro is a "simple" analogue sensor. Any math you want to do, you'll have to do on the (virtual) brick.

= Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Thu Nov 15, 2012 8:10 am
Profile WWW
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Ring It Up Gripper bot has no arm encoder
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
Profile
Site Admin
Site Admin
User avatar

Joined: Tue Oct 09, 2012 10:34 am
Posts: 192
Post 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.

_________________
Ryan Cahoon
CMU Robotics Academy
RVW Software Developer

Robot Potato Head; Virtual NXT


Thu Nov 15, 2012 1:50 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Ring It Up Gripper bot has no arm encoder
rcahoon wrote:
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.


Thu Nov 15, 2012 2:07 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 30 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: No registered users and 2 guests


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

Search for:
Jump to:  
cron



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.