Print

Print


Our team tested this pretty well when we found this code and I'm pretty confident that executing the loop as described while letting the robot sit stationary will cure gyro drift.  I"ll be curious to see if you can find a case where it doesn't work... we haven't.

Also, it may be that the sensor is returning floating point values, not integer values.  If that's the case, then NaN is a valid value , Check the wikipedia page for NaN for all sorts of good info.  

I don't think that this is a programming error.  It seems reasonable to me that while it's calibrating, it would return invalid numbers.  Personally I think the source of the problem is Lego not providing an adequate 'reset' block.  The reset just clears the values, it doesn't clear the drift.  The fact that you have to read the angle+rate and then the rate to get it to recalibrate seems insane to me, but I have yet to find a better solution.

-Frank


On Tue, Oct 28, 2014 at 10:19 PM, Anant Narayanan <[log in to unmask]> wrote:
Sorry for being obscure.  As an engineer, I want to understand the problem!  The workaround may not work all the time.  There is no earthly reason for a data to be outside range unless there is no data validation (GIGO principle).  Clearly there is a programming error in addition to the signal multiplexing issue.

Also, I wonder what causes the NaNs to disappear?  Every set of 8 bits  (or 16 bits) is always a number, and thus the notion of NaNs is quite synthetic to a digital signal unless one gets into symbolic mutations (ASCII, etc.).  Another cause may be that the sensor generates +0 when the software expects -0 at start (or vice versa).  This may be due to assigning one bit for sign and rest for the binary representation of a number.

Thanks for the wonderful thread.  I think I am closer to understanding the source of the problem.

----------------------------------------------------------
Anant S Narayanan
Founder & Executive Director

McLean Robotics Institute
McLean VA 22102
202-421-3826 (cell)
[log in to unmask]

-----------------------------------------------------------


On Tue, Oct 28, 2014 at 9:40 PM, Frank Levine <[log in to unmask]> wrote:
My background is in software, not hardware so I'm not sure I follow your explaination.  The beauty of this reset block is that it takes the guess work out.  Is it 2 seconds?  5 seconds?  Doesn't matter now, just wait for the NaN's to clear out.

-Frank
(sent via my iPhone, so pardon any spelling errors)

On Oct 28, 2014, at 9:28 PM, Anant Narayanan <[log in to unmask]> wrote:

Thanks.  For two years we have been using a 2 second wait after gyro reset - this has fixed most problems but the drift remains.  The explanation for this 2 second wait is quite simple.  The gyro sensor is a miniature mechanical device with a microscopic spinning device on a chip (MIMS).  The rotations etc are picked up by a Hall effect sensor or equivalent.  When one does a reset, the device has to spin down.  2 seconds was usually adequate, 5 seconds added little statistically (from dozens of experiments we did later year).

What I am picking up from you is that there may be software/hardware anomalies on the signal pickup circuit inside the sensor.  The A/D digitization is usually implemented in hardware on such devices and is rarely problematic.  However due to the option to read rate and heading, there has to be signal multiplexing which can lead to synchronization errors when the receiver and transmitter are not in clock sync.

The VexIQ devices have programmable microcontroller in all the sensors - I think this is the sounder approach than cheaper passive sensors in the Lego line.

Notwithstanding all the problems, we have had great overall success with the gyro sensor.  We have been using gyro lock on moves ( just give heading and distance and the my block moves the robot the required distance at the specified heading), with a number of variants.

We even implemented a never lost system that lets a robot return home after 3-4 missions even if some/all missions don't work along the way.

The learning has been great.  But there is much more to be done.  If only there were more time!

Thanks for sharing the link.

Best of luck,

Nari Narayanan
______________________________________
Anant S Narayanan
Founder & Executive Director
McLean Robotics Institute
(202) 421-3826 (mobile)
[log in to unmask]
______________________________________,

On Oct 28, 2014 9:02 PM, "Frank Levine" <[log in to unmask]> wrote:
Nari,

  This thread seems to indicate that switching from angle+rate mode to angle mode causes the gyro to go into reset mode.:

  While it's calibrating, it returns NaN's that you can detect (not >= or < 0) and wait for it to reset.  If you put the code into a loop until the gyro starts returning numbers you'll see that it usually takes 2-3 seconds to get through the loop.  My team uses beeps at the beginning and end of the loop so they know to keep the robot still, and we have a standalone program we run to do it right before we start running missions.  Furthermore we did some experiments where we moved the robot around while it was 'calibrating'.  It takes the same amount of time, but when it's done the gyro is drifting all over the place.  If you then set the robot on the table and run the program again the drift is gone... it's awesome.  My suggestion would be to implement it as a quick program (or better yet, have your team read and understand the presentation and implement it).  My team thought that the whole concept of "Not a Number" was totally cool.
  On a side note - as a professional software engineer I can say that NaN's have wasted more than a few days of my time over the years.  They're a serious pain in the rear to detect and they cause the software to behave in all sorts of strange ways.
  Finally, I don't think it's reasonable to expect 4th and 5th graders to figure this one out.  I showed it to my team and I explained what was going on.  They all learned a little bit about computer representations of numbers and have a little more insight into how things like yaw-rate sensors work.  In the end my goal is to have these kids learn stuff, not spend hours being frustrated by a sensor that has no documentation on how to properly calibrate :)

-Frank



On Tue, Oct 28, 2014 at 8:28 PM, Anant Narayanan <[log in to unmask]> wrote:

Frank:

Thanks for.sharing.  Our teams have had a lot of trouble with gyro drift last year and this and we have some fixes using cooling sprays etc.

Your procedure doesn't fix gyro drift as much as detects its nonocurrence, unless I am missing something.  So we could be waiting for ever for the problem to correct itself.

I also was unsure about the meaning of reading the angle and rate at the same time.  Are these in quick succession?  Or did you mean parallel programming?

Also, if a number is not greater, lesser or equal to zero, there is some representation error in the transmission protocol, as all sensor data values are software generated, since the Lego sensor does not have a microprocessor in it.  In other words, you seem to be suggesting that the gyro drift is a synthetic problem caused by a software bug rather than a hardware flaw.

Nari Narayanan

______________________________________
Anant S Narayanan
Founder & Executive Director
McLean Robotics Institute
(202) 421-3826 (mobile)
[log in to unmask]
______________________________________,

On Oct 28, 2014 2:11 PM, "Frank Levine" <[log in to unmask]> wrote:
If you're using the Gyro, you'll want to make sure you're resetting it properly.  The best gyro reset code that we have found comes from the Hoosier Girlz via Droid Robotics advanced lesson #5.  If your Gyro occasionally starts to drift, this is for you...

While gyro is calibrating, it returns 'NaN' which stands for "Not a Number".  NaN's are a serious pain and cause all sorts of problems in real world code.  Taking the square root of -1 is one way to geneate a NaN in 'real' programming languages.  Anyways, NaN's have the interesting property that they return false when compared to other numbers.  This allows the clever EV3 programmer (ie, the Hoosier Girlz) to detect them and wait for the Gyro to reset.
Step 1: Read both the Angle and Rate at the same time
Step 2: Start a loop
Step 3: Read the angle
Step 4: Check to see if the Angle is >= 0
Step 5: Check to see if the angle is < 0
Step 6: "or" the results of steps 4,5 together
If the result of step 6 is true, then the number is >=0 or <0 so you're good to go
If the result of step 6 is false, then the number must be NaN (it's not >=0 or <0) so repeat the loop.

This solved all of our Gyro drift problems and I think it is something that all teams should know and understand.  Honestly, the 'reset' block should have come standard with the EV3 environment.  It's hard enough to use the Gyro when it's calibrated correctly.  When it's not it can waste valuable team time.

In response to Droid Robotic's efforts, our team shared their Proportional Control turn code (which is made even better with a calibrated gyro!).  If your teams have any basic building blocks that they want to share, the guys at Droid Robotics appear to be compiling a very nice set of building blocks that are easy to understand and explain to FLL kids.  What I like about them is that they don't just re-post solutions, they take the time to understand what's going on and explain it in a way that kids their age will understand.  I think it's a great project and I fully support what they're doing.

Thanks,
Frank Levine
Coach "The Construction Mavericks"







On Tue, Oct 28, 2014 at 1:49 PM, Nancy Nguyen <[log in to unmask]> wrote:
Just goes to show you that every team is different and has different experiences. My team has had great success with the gyro sensor. Does not affect the speed of our robot and makes nice precise turns in tight spaces. The kids have not been very successful with the color sensor. They feel it is more trouble than it's worth. Like I said, different experiences for different teams.

Sent from my iPhone
-Nancy Nguyen

On Oct 28, 2014, at 1:03 PM, MARVIN HOM <[log in to unmask]> wrote:

Try scrimmaging against a team that uses sensors. The improvement with sensors vs no sensors will be obvious.

..but don't use the gyro. It can be made to work reliably but it's performance will be agonizingly slow.

-Regards,
Marvin Hom
Coach
Falls Church, VA

On Oct 28, 2014, at 12:51 PM, Betsy T. Wilco <[log in to unmask]> wrote:

Honestly, I want my kids to learn to use sensors, but before tournament I am very "hands-off" with any building or programming. I ask them questions, I cheer them on, but all decisions are made by the kids. So my opinion is that if they don't want to use sensors, they should be alloewed to make that decision.  Possibly they just aren't ready. But in any case, they will learn a ton from participating at all. They will see other teams using different methods at tournament and want to try some of them when they come back. And, next year the experienced kids may encourage the newbies to new heights. Or not. But it is their work, their bot, their strategy that counts. Just one opinion!

Betsy T Wilco
Gifted Resource Teacher
Prince William County Schools

From: First Lego League in Virginia and DC <[log in to unmask]> on behalf of VA-DC Referee Advisor <[log in to unmask]>
Sent: Tuesday, October 28, 2014 12:47 PM
To: [log in to unmask]
Subject: Re: [VADCFLL-L] Between runs
 
I haven't been an FLL coach, but you might try the blindfolded instructions approach:

Go forward 4 steps.  Turn right.  Move forward until you hit the wall.  Turn left.  Go three steps.  Line yourself up with the table.  etc...

It's fun for team building, too!

Steve

On Tue, Oct 28, 2014 at 12:33 PM, Fredrik Nyman <[log in to unmask]> wrote:
Somewhat off-topic, but:

I'm having a hard time getting my kids to use sensors.  Since the sensors (color and gyro in particular) are pretty finicky, the kids think that there isn't much of an advantage of using them compared to doing navigation in terms of motor rotations.  

How is everyone else doing?  Have you found a way to convince the kids that the sensors are worthwhile?




To UNSUBSCRIBE or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.htmland select "Join or leave the list". 
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visithttps://listserv.jmu.edu/archives/vadcfll-announcements-l.html to subscribe.

To UNSUBSCRIBE or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.htmland select "Join or leave the list". 
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visithttps://listserv.jmu.edu/archives/vadcfll-announcements-l.html to subscribe.


To UNSUBSCRIBE or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.html and select "Join or leave the list".
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visit https://listserv.jmu.edu/archives/vadcfll-announcements-l.html to subscribe.

To UNSUBSCRIBE or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.html and select "Join or leave the list".
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visit https://listserv.jmu.edu/archives/vadcfll-announcements-l.html to subscribe.


To UNSUBSCRIBE or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.html and select "Join or leave the list".
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visit https://listserv.jmu.edu/archives/vadcfll-announcements-l.html to subscribe.




To UNSUBSCRIBE or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.html and select "Join or leave the list".
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visit https://listserv.jmu.edu/archives/vadcfll-announcements-l.html to subscribe.