View Single Post
  #18   Spotlight this post!  
Unread 04-06-2010, 05:31 PM
mikets's Avatar
mikets mikets is offline
Software Engineer
FRC #0492 (Titan Robotics Club)
Team Role: Mentor
Join Date: Jan 2010
Rookie Year: 2008
Location: Bellevue, WA
Posts: 799
mikets is a name known to allmikets is a name known to allmikets is a name known to allmikets is a name known to allmikets is a name known to allmikets is a name known to all
Re: Unexpected results from Encoder::GetRate()

I am sorry. I am probably not helping with your particular problem. I am merely trying to point out that in the iterative robot class, don't count on the period being accurate and use it as dt for differentiation or integration. You said your Update_Rate is 100 Hz. That makes the period 10 ms. If you put "time = time + 1/Update_Rate" in your loop, your time is really summing a constant 10 ms on every loop period, not real time. If you do this instead:
class MyRobot: public IterativeRobot
    UINT32 m_timestamp;

    void AutonomousInit()
        m_timestamp = GetFPGATime();
    void AutonomousPeriodic()
        UINT32 timeCurr = GetFPGATime(); // in usec
        float period = (float)(timeCurr - m_timestamp)/1000000.0;
        m_timestamp = timeCurr;
        printf("loop period is %f\n", period);
"period" will be the accurate loop interval that can be used as dt in your differentiation or integration. In theory period should print out 0.01s (10 ms), but in our case, it is way off. It could be because our loop execution took longer than the 10ms to execute that may cause a period to be skipped in some cases. Therefore, as a good practice, never use the period you set in any time critical calculations.

Last edited by mikets : 04-06-2010 at 05:52 PM.
Reply With Quote