Go to Post FIRST is similar to real life in that nothing is perfect and you have to deal with the circumstances as they arise and make the best of it! - Sean_330 [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 30-01-2013, 19:28
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Ether View Post
Why do RT timed loops "eat a lot of CPU usage" ? Is the context switching overhead for a timed loop really that much different from a "waited" loop?


I'm not really sure.

In all tests I've done, they just do.

It's likely the fact that the code is actually running faster than a waited loop.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #17   Spotlight this post!  
Unread 30-01-2013, 19:38
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by apalrd View Post
It's likely the fact that the code is actually running faster than a waited loop.
Running faster, as in "task period is shorter". Makes sense.


  #18   Spotlight this post!  
Unread 30-01-2013, 20:16
simpsonboy77 simpsonboy77 is offline
Registered User
AKA: Garrett Dicken
FRC #0041 (RoboWarriors)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2005
Location: New Jersey
Posts: 91
simpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

I'm not certain about labview's implementation but in C++ you can request the system clock for its time since it powered up. This has a resolution of 1ms. Before you do your dt calculation you can figure out how much time has passed by asking for the current system time and subtracting the last time you asked for the time. I think this is much better than any loop that you state how long it takes. This will account for anything that changes the cpu load, perhaps vision code or the garbage collector.

new_time = current_sys_time
do pid calculations with dt = new_time - old_time
old_time = new_time
__________________
2017 Shenzhen, China Regional CSA
2013 - Present MAR Control System Adviser and FTAA
2009 - Present Programming an Electrical Mentor Team 41
2007 - 2008 Team 41 Lead Programmer, Electrical
2005 - 2008 Team 41 Member
2008 NYC Regional Winner
  #19   Spotlight this post!  
Unread 30-01-2013, 20:25
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by simpsonboy77 View Post
I'm not certain about labview's implementation but in C++ you can request the system clock for its time since it powered up. This has a resolution of 1ms. Before you do your dt calculation you can figure out how much time has passed by asking for the current system time and subtracting the last time you asked for the time. I think this is much better than any loop that you state how long it takes. This will account for anything that changes the cpu load, perhaps vision code or the garbage collector.

new_time = current_sys_time
do pid calculations with dt = new_time - old_time
old_time = new_time

The same thing exists in LabVIEW. It's the 'Tick Count' block with the same 1ms accuracy.

I *believe* there's a more accurate Tick Count in the RT section that can measure from other clock sources. BUT, I haven't ever needed more than ms accuracy.

In an ideal realtime world there is no garbage collector, all of the RAM is statically allocated in blocks and never dynamically allocated. In an ideal realtime world, people also don't try to run vision on the same processor that runs hard RT control loops without actual RT control loops, when the RT task is already using the majority of the CPU, and expect the non-RT control loop to be reasonably consistent.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #20   Spotlight this post!  
Unread 30-01-2013, 20:27
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by simpsonboy77 View Post
I'm not certain about labview's implementation but in C++ you can request the system clock for its time since it powered up. This has a resolution of 1ms.
If the resolution of the "system clock" is truly 1 millisecond (as you said), then if you're running a control loop at 10ms, you could have an error up to 20%.

There's a much more accurate system timer that is available:

Timer::GetPPCTimestamp() has low overhead and returns time in seconds in double precision with 1/3 microsecond
resolution
. According to the WPILibC++Source20120204rev3111 source code date February 4 2012, it uses a 64-bit
counter incrementing at 33MHz, which if true wouldn't overflow in your lifetime. Warning: I'm told that earlier versions
of GetPPCTimestamp() used a 32-bit counter instead of 64, and would rollover every 130 seconds. Check the source
code on your machine to make sure.



Last edited by Ether : 30-01-2013 at 20:42.
  #21   Spotlight this post!  
Unread 31-01-2013, 09:39
kenfox kenfox is offline
Registered User
FRC #3322 (Eagle Imperium)
Team Role: Mentor
 
Join Date: Jan 2013
Rookie Year: 2013
Location: Ann Arbor, MI
Posts: 52
kenfox is a glorious beacon of lightkenfox is a glorious beacon of lightkenfox is a glorious beacon of lightkenfox is a glorious beacon of lightkenfox is a glorious beacon of light
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Ether View Post
There's a much more accurate system timer that is available
There are 3 ways to get a timestamp in the 2013 WPILib C++ code. All of them are black box calls into lower level code, so the information here comes from the comments. If I have time tomorrow I will test timing on the cRIO and cRIO-II.

Timer::GetFPGATimestamp() and ::GetClock() -- double precision seconds since FPGA was reset. Uses FPGA clock so is synchronized with other FPGA timers. FPGA clock counts time in microseconds with an unsigned 32-bit integer. Rolls over every 71.6 minutes. (Timer::Reset does NOT reset the rollover.)

Timer::GetPPCTimestamp() -- double precision seconds since cRIO was powered on. Uses PPC system clock so is not synchronized with FPGA timers. Hardcoded assumption of 33MHz in WPILib. The counter is fetched with niTimestamp64() so it's probably 64-bit and rolls over every 9 billion minutes.

::GetTime() -- double precision seconds since January 1, 1970. This uses the vxWorks real-time clock which I can't find documentation on. The API allows nanosecond precision which seems optimistic.
  #22   Spotlight this post!  
Unread 31-01-2013, 10:28
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,554
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Anyone know if there is a common high-resolution timer that can be called from LabVIEW? I'm only familiar with the millisecond resolution timer that's available from the timing palette.
  #23   Spotlight this post!  
Unread 31-01-2013, 10:51
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Tom Line View Post
Anyone know if there is a common high-resolution timer that can be called from LabVIEW? I'm only familiar with the millisecond resolution timer that's available from the timing palette.
Most graphical languages have built-in support for C. Perhaps a LabVIEW guru could post a simple example how to call the 3 timers kenfox listed.


  #24   Spotlight this post!  
Unread 31-01-2013, 10:54
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by kenfox View Post
There are 3 ways to get a timestamp in the 2013 WPILib C++ code. All of them are black box calls into lower level code, so the information here comes from the comments. If I have time tomorrow I will test timing on the cRIO and cRIO-II.
I wonder:

1) how many layers of code are wrapped around each of these timers, and

2) can each one be used in a critical section, and

3) how long does each take to execute, and

4) is there anybody who has authoritative answers to these questions


  #25   Spotlight this post!  
Unread 31-01-2013, 11:14
Mark McLeod's Avatar
Mark McLeod Mark McLeod is offline
Just Itinerant
AKA: Hey dad...Father...MARK
FRC #0358 (Robotic Eagles)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Hauppauge, Long Island, NY
Posts: 8,906
Mark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Tom Line View Post
Anyone know if there is a common high-resolution timer that can be called from LabVIEW? I'm only familiar with the millisecond resolution timer that's available from the timing palette.

Look under Real Time -> RT Timing

They use a 32-bit internal counter.
Attached Thumbnails
Click image for larger version

Name:	RT-Wait.png
Views:	20
Size:	1.4 KB
ID:	13731  Click image for larger version

Name:	RT-WaitNxtMultiple.png
Views:	13
Size:	1.5 KB
ID:	13732  Click image for larger version

Name:	RT-TickCount.png
Views:	18
Size:	1.1 KB
ID:	13733  
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 31-01-2013 at 11:18.
  #26   Spotlight this post!  
Unread 31-01-2013, 11:16
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Mark McLeod View Post
Look under Real Time -> RT Timing
I could be wrong, but in the context of this thread I think he wants to read a high resolution timer, not wait.


  #27   Spotlight this post!  
Unread 31-01-2013, 11:18
Mark McLeod's Avatar
Mark McLeod Mark McLeod is offline
Just Itinerant
AKA: Hey dad...Father...MARK
FRC #0358 (Robotic Eagles)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Hauppauge, Long Island, NY
Posts: 8,906
Mark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Ether View Post
I could be wrong, but in the context of this thread I think he wants to read a high resolution timer, not wait.

I added the Tick Counter.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle
  #28   Spotlight this post!  
Unread 31-01-2013, 11:38
BitTwiddler's Avatar
BitTwiddler BitTwiddler is offline
electronics/programming mentor
AKA: Mr Tanguay
FRC #1726 (N.E.R.D.S.)
Team Role: Mentor
 
Join Date: Oct 2008
Rookie Year: 2006
Location: Sierra Vista, AZ
Posts: 254
BitTwiddler is on a distinguished road
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Ether View Post
Most graphical languages have built-in support for C. Perhaps a LabVIEW guru could post a simple example how to call the 3 timers kenfox listed.


While I do not claim the role of LabVIEW guru here, I remember once using LabVIEW's Code Interface Node (CIN) capability to write C code at a low level. I imagine this capability still exists within LabVIEW. I think it does but it has been years since I used it.
  #29   Spotlight this post!  
Unread 31-01-2013, 13:24
kenfox kenfox is offline
Registered User
FRC #3322 (Eagle Imperium)
Team Role: Mentor
 
Join Date: Jan 2013
Rookie Year: 2013
Location: Ann Arbor, MI
Posts: 52
kenfox is a glorious beacon of lightkenfox is a glorious beacon of lightkenfox is a glorious beacon of lightkenfox is a glorious beacon of lightkenfox is a glorious beacon of light
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Ether View Post
1) how many layers of code are wrapped around each of these timers
Generally 2 layers + the hardware or whatever the black box routines require. WPILib -> ChipObject (FPGA timer), WPILib -> NI (PPC timer), and WPILib -> vxWorks. All of the WPILib routines are short enough to be inlined for free, but the code structure doesn't allow it.

Quote:
Originally Posted by Ether View Post
2) can each one be used in a critical section
WPILib uses these routines outside of critical regions, so I assume they are either lock-free or have their own independent locks.

Quote:
Originally Posted by Ether View Post
3) how long does each take to execute, and

4) is there anybody who has authoritative answers to these questions
Testing may be the best way to answer these questions, but I'm also curious about the recommended/official way to handle time. It looks like the FPGA clock is preferred since the other ways of grabbing a timestamp aren't used by WPILib except in Vision. I'll collect some data on our cRIOs tomorrow.
  #30   Spotlight this post!  
Unread 31-01-2013, 13:39
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by kenfox View Post
WPILib uses these routines outside of critical regions, so I assume they are either lock-free or have their own independent locks.
My concern was along the following lines. If any of the layers has code like this (pardon the X86speak):

Code:
INCORRECT!!
cli   // disable interrupts
/* do something uninterruptable here */
sti   // enable interrupts
... instead of this:

Code:
CORRECT:
pushf // save interrupt state
cli   // disable interrupts
/* do something uninterruptable here */
popf  // restore saved interrupt state
.. then you can't reliably use cli in your application code.


Quote:
It looks like the FPGA clock is preferred since the other ways of grabbing a timestamp aren't used by WPILib except in Vision.
What the overhead of accessing the FPGA, compared to reading the PPC clock?

Quote:
Testing may be the best way to answer these questions ... I'll collect some data on our cRIOs tomorrow.
Excellent !


Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 02:22.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi