Go to Post Leave FIRST? That's an option? =) - treffk [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
  #1   Spotlight this post!  
Unread 08-03-2016, 13:12
David Lame David Lame is offline
Registered User
FRC #0247
 
Join Date: Feb 2015
Location: Berkley, MI
Posts: 88
David Lame is a jewel in the roughDavid Lame is a jewel in the roughDavid Lame is a jewel in the roughDavid Lame is a jewel in the rough
Timing, threads, the Field Management System, etc

I understand the basics of how FMS interacts with the robot. It calls the init function when it enters a new phase, and it calls the periodic function periodically while in the phase. I've read that it calls the periodic function every 10 milliseconds, but I don't know if that's correct, and I've never timed it.

Now what I'm wondering is what really happens if you do things that take up a lot of processor time, or perhaps just clock time.

For example, if you write in teleopPeriodic()
{
Thread.sleep(15);
}

when will the next call be made to teleopPeriodic() be made? 15 milliseconds after the last one? 25 milliseconds?

And then there are threads. There are certain things that come up that I know must be multithreaded behind the scenes. (E.g. PIDControllers)

Can I set up my own threads? There's a control loop that I am thinking about using, but 10 milliseconds between updates is too slow. If I just launched a thread to take care of that, could I update it much faster?

And loops? What if I code an infinite loop in autonomous.

autonomousPeriodic()
{
while (2+2==4)
{
System.out.println("I am still in autonomous");
}
}

Will that mean that it will run forever, and teleopInit() will never be called?




All right, those are very general questions that could have very complicated answers. What I am really looking for is a document from FIRST/National Instruments/WPI that addresses the issue.

In case it matters, we use Java with the Iterative robot model. I probably ought to use the command based robot model, but iterative was actually closer to what I wrote professionally, so that's what I do, and what I have taught since our team switched from Labview. I have now begun wondering if I am projecting my professional code behavior onto Java. Professionally, I wrote code that had to execute in a short time window because it was called periodically in an interrupt service routine. I'm not sure that's how the FMS/robot code actually works, and am wondering what would happen if I spawned a thread in teleopInit() that would go out and read my sensors and update motor speed more often than the default calls to teleopPeriodic().
  #2   Spotlight this post!  
Unread 08-03-2016, 13:23
nickbrickmaster's Avatar
nickbrickmaster nickbrickmaster is offline
Not Allowed Near Power Tools
AKA: Nick Schatz
FRC #3184 (Blaze Robotics)
Team Role: Leadership
 
Join Date: Jan 2015
Rookie Year: 2014
Location: Eagan MN
Posts: 165
nickbrickmaster is an unknown quantity at this point
Re: Timing, threads, the Field Management System, etc

The robot calls periodic methods at 50hz. You can start your own threads if you want. If you write an infinite loop in a periodic method, then no other control methods will be called, as there is a single main thread that reads FMS/input and calls control methods. If you have code that takes too much time, the robot well wait until that is finished. If you want more control over timing, such as faster updates, look into the SampleRobot class.
__________________
I have approximate knowledge of many things.

FRC 3184: 2014-, FTC 10648: 2015-
  #3   Spotlight this post!  
Unread 08-03-2016, 15:31
Bryan Herbst's Avatar
Bryan Herbst Bryan Herbst is offline
Registered User
AKA: Bryan
FRC #2052 (KnightKrawler)
Team Role: Mentor
 
Join Date: Sep 2007
Rookie Year: 2007
Location: Minneapolis, Minnesota
Posts: 545
Bryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond reputeBryan Herbst has a reputation beyond repute
Re: Timing, threads, the Field Management System, etc

The good news is that the WPI Library is all open source, so you can look at all the bits and pieces to find many of the answers to these questions.

You can find the source code at usfirst.collab.net.

Quote:
Originally Posted by David Lame View Post
I understand the basics of how FMS interacts with the robot. It calls the init function when it enters a new phase, and it calls the periodic function periodically while in the phase. I've read that it calls the periodic function every 10 milliseconds, but I don't know if that's correct, and I've never timed it.
There isn't a set rate at which the periodic methods are called.

If you open up the IterativeRobot class, you will find that there is a big infinite loop that checks which state the robot is in, and calls the appropriate periodic method whenever nextPeriodReady() returns true.

As per the documentation on that method, this happens whenever a packet is received from the driver station, which should be about 20ms (50Hz).

Quote:
Originally Posted by David Lame View Post
Now what I'm wondering is what really happens if you do things that take up a lot of processor time, or perhaps just clock time.

For example, if you write in teleopPeriodic()
{
Thread.sleep(15);
}

when will the next call be made to teleopPeriodic() be made? 15 milliseconds after the last one? 25 milliseconds?
Assuming the robot received a driver station packet during that 15ms that your code was sleeping, it will be called again immediately (well, as soon as execution can iterate through the control loop again).

Note that the DriverStation instance used by the RobotBase to update your robot polls for updates in a separate thread, so sleeping in your code won't delay any incoming packets from the DS.

Quote:
Originally Posted by David Lame View Post
And then there are threads. There are certain things that come up that I know must be multithreaded behind the scenes. (E.g. PIDControllers)

Can I set up my own threads? There's a control loop that I am thinking about using, but 10 milliseconds between updates is too slow. If I just launched a thread to take care of that, could I update it much faster?
Yes you can create your own threads. Just as you would in any other Java program, you can simply create a new Thread object and call start() on it.

As to whether you can make it update much faster- maybe.

First, I urge you to consider the physical limitations of your robot. Even if your code is attempting to do something every 1ms, can your robot physically do anything meaningful in that time?

Second, your motor controllers have technical limitations as well. Here's the Talon SRX documentation. The default control frame period (i.e. the maximum rate at which it accepts new input) is 10ms (see section 20.6), and the smallest you can go is 1ms. However, going down to 1ms increases CAN bus utilization by 15% (see section 16.23). There are tradeoffs to consider here.

You also have to consider RoboRIO CPU usage- the faster one thread is updating, the slower another thread is updating. Watch your CPU utilization carefully to make sure you aren't starving more important threads of resources.

Quote:
Originally Posted by David Lame View Post
And loops? What if I code an infinite loop in autonomous.

autonomousPeriodic()
{
while (2+2==4)
{
System.out.println("I am still in autonomous");
}
}

Will that mean that it will run forever, and teleopInit() will never be called?
Yes that code will run forever.

Note that motor controllers may have certain safety features enabled (see here). In addition to individual speed controller watchdogs, there is a system watchdog that will disable all output if it doesn't get feed for 125ms.
__________________
Team 2052- KnightKrawler
Mentor and volunteer
  #4   Spotlight this post!  
Unread 08-03-2016, 16:28
virtuald's Avatar
virtuald virtuald is offline
RobotPy Guy
AKA: Dustin Spicuzza
FRC #1418 (), FRC #1973, FRC #4796, FRC #6367 ()
Team Role: Mentor
 
Join Date: Dec 2008
Rookie Year: 2003
Location: Boston, MA
Posts: 1,102
virtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant future
Re: Timing, threads, the Field Management System, etc

Regarding while loops:
Code:
while (2+2==4) {
    System.out.println("I am still in autonomous");
}
If you're ever watching a match, and a Java/C++ team moves/does something in autonomous, but doesn't do anything during teleop... most of the time it's because they have a while loop checking for some condition that didn't occur that they thought would occur.

While loops are evil in robot code. Prefer not to use them (with a very few limited exceptions).

Threads are also evil (once again, with exceptions) in robot code and when used improperly can lead to difficult to diagnose bugs, prefer asynchronous constructs such as state machines instead.
__________________
Maintainer of RobotPy - Python for FRC
Creator of pyfrc (Robot Simulator + utilities for Python) and pynetworktables/pynetworktables2js (NetworkTables for Python & Javascript)

2017 Season: Teams #1973, #4796, #6369
Team #1418 (remote mentor): Newton Quarterfinalists, 2016 Chesapeake District Champion, 2x Innovation in Control award, 2x district event winner
Team #1418: 2015 DC Regional Innovation In Control Award, #2 seed; 2014 VA Industrial Design Award; 2014 Finalists in DC & VA
Team #2423: 2012 & 2013 Boston Regional Innovation in Control Award


Resources: FIRSTWiki (relaunched!) | My Software Stuff
  #5   Spotlight this post!  
Unread 08-03-2016, 16:36
MrRoboSteve MrRoboSteve is offline
Mentor
AKA: Steve Peterson
FRC #3081 (Kennedy RoboEagles)
Team Role: Mentor
 
Join Date: Mar 2012
Rookie Year: 2011
Location: Bloomington, MN
Posts: 582
MrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond repute
Re: Timing, threads, the Field Management System, etc

^^ true

A good mental model is to imagine there's an implicit loop around your code that gets invoked each time a packet arrives from the DS. You don't want explicit loops that repeatedly check for something as well.

You should also assume that you don't know how long it will be between invocations of your code. You can see this by logging the actual time between invocations -- that value will have quite a bit of jitter when tethered, and will be much more jittery during an actual match.

I sometimes think it would be good to add a small amount of artificial jitter to WPILib, to better simulate real conditions.
__________________
2016-17 events: 10000 Lakes Regional, Northern Lights Regional, FTC Burnsville Qualifying Tournament

2011 - present · FRC 3081 Kennedy RoboEagles mentor
2013 - present · event volunteer at 10000 Lakes Regional, Northern Lights Regional, North Star Regional, Lake Superior Regional, Minnesota State Tournament, PNW District 4 Glacier Peak, MN FTC, CMP
http://twitter.com/MrRoboSteve · www.linkedin.com/in/speterson

Last edited by MrRoboSteve : 08-03-2016 at 16:37. Reason: added last sentence.
  #6   Spotlight this post!  
Unread 08-03-2016, 19:13
David Lame David Lame is offline
Registered User
FRC #0247
 
Join Date: Feb 2015
Location: Berkley, MI
Posts: 88
David Lame is a jewel in the roughDavid Lame is a jewel in the roughDavid Lame is a jewel in the roughDavid Lame is a jewel in the rough
Re: Timing, threads, the Field Management System, etc

Thanks to all. I'll put you all in for the Gracious Professionalism award.


In all seriousness, these were some very helpful replies, and answered some questions I have wondered about.
  #7   Spotlight this post!  
Unread 13-03-2016, 23:59
jkoritzinsky jkoritzinsky is offline
Registered User
AKA: Jeremy Koritzinsky
FRC #4786 (Nicolet F.E.A.R.)
Team Role: Mentor
 
Join Date: Apr 2014
Rookie Year: 2014
Location: Glendale, Wisconsin
Posts: 78
jkoritzinsky will become famous soon enoughjkoritzinsky will become famous soon enough
Re: Timing, threads, the Field Management System, etc

Quote:
Originally Posted by virtuald View Post
Threads are also evil (once again, with exceptions) in robot code and when used improperly can lead to difficult to diagnose bugs, prefer asynchronous constructs such as state machines instead.
Threads are always evil. Way too easy to put yourself into a deadlock/livelock or put your code in an "impossible" situation with bad use of concurrency constructs. Really the problem is mutable state + threading + bad use of concurrency constructs.
__________________
Nicolet F.E.A.R. (Team 4786) - Aerial Assist - Programming Manager
Nicolet F.E.A.R. (Team 4786) - 2015+ - Junior Mentor

SuperScouter for FRC Developer
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 01:32.

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