OCCRA
Go to Post Have you been formally diagnosed as a masochist, or are you just a mentor? - GeeTwo [more]
Home
Go Back   Chief Delphi > Technical > Programming > NI LabVIEW
CD-Media  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 04-01-2018, 10:14 AM
Mr.R^2 Mr.R^2 is offline
Registered User
FRC #6762
 
Join Date: Apr 2017
Location: Hillsboro, NH
Posts: 50
Mr.R^2 is on a distinguished road
Teleop breaking auto with Phoenix...

We just finished our season, and though we may be shifting from Labview to Java (due to unbearable build and compile times, which could be entirely due to bloated code on our part), I am wondering about an issue we had this year with our auto.

The issue is, during testing, if we implement teleop before autonomous, the motors stall when triggered. This seems to be true even if we disable the watchdog.

The error we get in the driverstaition is either that the joystick loop is not running fast enough (odd in that we do not invoke the joystick vi during auto. We removed that code from the auto program.) or that the drive motor is not running fast enough (this is the error we got before removing the drive motors from periodic tasks).

We are using talons through CAN. We have removed the drive motor reference in periodic tasks, and in auto, we access the Talons directly. In Teleop, we use the four motor vi (defined in begin) to run arcade drive. With two talons in follow mode.

My question is, is there a way to close the four motor reference after teleop exits so it does not crash the auto program?

I am assuming we have created a race condition where two controls are trying to set the talons at once.

Of course this is just a curiosity moving forward as the program works fine if auto runs before teleop (which it always does in the game).
Reply With Quote
  #2   Spotlight this post!  
Unread 04-01-2018, 11:55 AM
JayShower's Avatar
JayShower JayShower is offline
Registered User
AKA: Jay Schauer
FRC #1732 (Hilltopper Robotics)
Team Role: Programmer
 
Join Date: Feb 2017
Rookie Year: 2015
Location: Milwaukee
Posts: 101
JayShower is a glorious beacon of lightJayShower is a glorious beacon of lightJayShower is a glorious beacon of lightJayShower is a glorious beacon of lightJayShower is a glorious beacon of lightJayShower is a glorious beacon of light
Re: Teleop breaking auto with Phoenix...

If you post your code, that would help. Also the build times could be your code, or you're just using a slower computer. Build times for us this year were ~5 sec, and we had ~90 class files to compile.
Reply With Quote
  #3   Spotlight this post!  
Unread 04-02-2018, 10:24 AM
JeffB JeffB is offline
Registered User
FRC #5052 (RoboLobos)
Team Role: Mentor
 
Join Date: Apr 2015
Rookie Year: 2014
Location: Austin
Posts: 318
JeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond repute
Re: Teleop breaking auto with Phoenix...

Quote:
Originally Posted by Mr.R^2 View Post
My question is, is there a way to close the four motor reference after teleop exits so it does not crash the auto program?

I am assuming we have created a race condition where two controls are trying to set the talons at once.

Of course this is just a curiosity moving forward as the program works fine if auto runs before teleop (which it always does in the game).
I'm not sure if you're still using LabVIEW or if you're discussing this in the context of Java.

But, I'd expect a similar behavior here.

The references aren't created in Teleop. They're created in Begin. If you close out references in Teleop, you're going to create a situation where you can only run motors in the first iteration. Every time afterwards, you'll get an error about invalid references.

The way to fix this would be to move the open from Begin to Teleop. That's not a great idea. You're going to add overhead that doesn't really offer you any gain. Opening and closing the references in each loop just means you don't have time to be doing other things.

The "get ref" that you're using in Teleop and Auton is essentially a "read global variable" call that gets the reference created, and stored, in Begin. The only time teleop should be using it is while teleop is running.

I'd be interested to see how you managed to get teleop to run continuously to have it running side by side with autonomous.

I doubt Phoenix has anything to do with what you're seeing. I could offer more advice if you attached your project. But, I've only got guesses at the moment.
__________________


Any thoughts I share are meant to be my interpretation of rules/events/intents. They shouldn't be viewed as anything even approaching an official viewpoint.
Reply With Quote
  #4   Spotlight this post!  
Unread 04-02-2018, 04:53 PM
Mr.R^2 Mr.R^2 is offline
Registered User
FRC #6762
 
Join Date: Apr 2017
Location: Hillsboro, NH
Posts: 50
Mr.R^2 is on a distinguished road
Re: Teleop breaking auto with Phoenix...

Thanks for your reply. I was having difficulty getting to the latest version of our code as we made many changes this weekend at the event. Here is the code before we made the edits at the event.

They are huge pngs. So, f you cannot follow them, let me know, and I will direct you to our git.

This version does still have the joystick references in auto, but I am quite certain we removed them in the more recent version of the code.

So, the issue is twofold ( or perhaps two separate issues).
1) Autonomous locks up the second the drive wheels begin turning.

2) It takes a very long time to push any edits to the rio. It only takes a few minutes if we are just deploying for current run (pressing the white arrow), but it does not seem to stick on reboot unless we build, deploy, set as startup. That process takes at least 15 minutes. In our first event, it locked up at the end of the build process (when it got to vision). We barely were able to make any edits to the code at the event. We overcame the complete lockup by reflashing the rio and re-installing all software in our driver station (also development computer). But, it still takes too long.
Attached Thumbnails
Click image for larger version

Name:	Auto.png
Views:	22
Size:	357.2 KB
ID:	23264  Click image for larger version

Name:	Begin.png
Views:	22
Size:	169.4 KB
ID:	23265  Click image for larger version

Name:	Periodic.png
Views:	23
Size:	202.0 KB
ID:	23266  Click image for larger version

Name:	Teleop.png
Views:	19
Size:	277.5 KB
ID:	23267  
Reply With Quote
  #5   Spotlight this post!  
Unread 04-02-2018, 06:14 PM
JeffB JeffB is offline
Registered User
FRC #5052 (RoboLobos)
Team Role: Mentor
 
Join Date: Apr 2015
Rookie Year: 2014
Location: Austin
Posts: 318
JeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond repute
Re: Teleop breaking auto with Phoenix...

It generally takes a bit of time to deploy, it's not the code. The reason things don't "stick" when you send with the white arrow (Run Arrow) is you're starting what's known as "Interactive Mode" It's meant for debugging/troubleshooting/developing. Once you're set, you build, deploy, run as startup and it'll stick with each reset. That's not surprising. (Scratch that. 15 minutes is surprising. I'm thinking up to 1-2 minutes. That frustrates many, myself included. But, 15 is a bit much. If you'd like, I can try handling the process on my end to see if I get a similar response).

It might be easier to see the git just to clean up the code(feel free to message me if you'd prefer not post in public). In a lot of places, you have wires hiding under structures and I'm mostly guessing which wire goes where. This may be part of the problem. If the wires aren't going where you expect them to, they might be bringing in bad values. You said the code works if you change the order, so that's less likely. But, it's still something I'd take a look at.

I'd try running with the Run Arrow. If you can replicate the behavior while running this way, it's worth running the code and placing probes (right-click the wires and choose Probe). With this, you can see what values are being sent.
__________________


Any thoughts I share are meant to be my interpretation of rules/events/intents. They shouldn't be viewed as anything even approaching an official viewpoint.
Reply With Quote
  #6   Spotlight this post!  
Unread 04-02-2018, 07:01 PM
Mr.R^2 Mr.R^2 is offline
Registered User
FRC #6762
 
Join Date: Apr 2017
Location: Hillsboro, NH
Posts: 50
Mr.R^2 is on a distinguished road
Re: Teleop breaking auto with Phoenix...

Thank you.
We can replicate the issue with the run arrow. Also, thank you for confirming that our deploy procedure is correct. Is it possible that the computer is just too slow? We do all of our testing on the classmate (Lenovo n22 I think it has 4 gigs of ram) from last year (our rookie season). It does take a while to do anything in Labview on it.

Here is our Git.


We just had not yet made this year's build public yet.
Reply With Quote
  #7   Spotlight this post!  
Unread 04-03-2018, 10:23 AM
JeffB JeffB is offline
Registered User
FRC #5052 (RoboLobos)
Team Role: Mentor
 
Join Date: Apr 2015
Rookie Year: 2014
Location: Austin
Posts: 318
JeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond repute
Re: Teleop breaking auto with Phoenix...

I'm going to go through some stream of consciousness here. So, things might not make great sense on a first read.

I started by opening up Autonomous Independent and hitting Ctrl+U (cleanup. Generally, I don't recommend this for a full Block Diagram. Instead, highlight the area and then do it. Here, I did it in the interest of time)

First thing I notice: There's a random constant 'U' being fed into the outer case structure but never used. I'm sure the compiler deletes this. But, you may want to as well.

"Auto Selector" and "autoProgram" are redundant. They're both meant to select an auton case and choose the appropriate case. If you're not using "Auto Selector" you can eliminate the outer case structure by right-clicking the border and choosing "Remove Case Structure." When you do this, the Auto Selector wires will break. You can delete this entire bit of code.

I'm assuming you read autoSpeed and straightAutoDistance outside of the loop because you eventually want to build more cases. If that's not the case, it'd be easier to move them inside.

In Begin.vi, you do have the safety turned on. It'd be strange to me this works at all. If you run a loop with a wait of 50ms for a count of N defined as (input time/50) to get the same duration, this should feed the watchdog and help with the safety. Is this something you're able to try? I've attached a quick update from my end showing the changes.

Something else I want you to try: go to Begin.vi. For any of the Talon Opens, double-click on them. Look at the Block Diagram specifically for the c_MotController_Create1 "Call Library Function Node" and tell me what color it is? There are two colors: light yellow (same color as Add, for example) or a darker orange. Which color is yours? If it isn't light yellow, we'll want to update your CTRE software. This might help with the deployment times you were running into. You can find one of the darker orange color ones on this page: http://zone.ni.com/reference/en-XX/h..._the_clf_node/ Ignore most of the text. If the color of your CLFN matches this, let's talk software update. If not, let's not worry about that.
Attached Files
File Type: vi Autonomous Independent.vi (30.1 KB, 6 views)
__________________


Any thoughts I share are meant to be my interpretation of rules/events/intents. They shouldn't be viewed as anything even approaching an official viewpoint.
Reply With Quote
  #8   Spotlight this post!  
Unread 04-03-2018, 10:23 AM
JeffB JeffB is offline
Registered User
FRC #5052 (RoboLobos)
Team Role: Mentor
 
Join Date: Apr 2015
Rookie Year: 2014
Location: Austin
Posts: 318
JeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond repute
Re: Teleop breaking auto with Phoenix...

Also, are you able to run your robot code now to probe the wires? Or, is it locked up in a bag and you won't be able to test things until later?
__________________


Any thoughts I share are meant to be my interpretation of rules/events/intents. They shouldn't be viewed as anything even approaching an official viewpoint.
Reply With Quote
  #9   Spotlight this post!  
Unread 04-03-2018, 12:16 PM
Mr.R^2 Mr.R^2 is offline
Registered User
FRC #6762
 
Join Date: Apr 2017
Location: Hillsboro, NH
Posts: 50
Mr.R^2 is on a distinguished road
Re: Teleop breaking auto with Phoenix...

JeffB,
Thank you for your help. That makes a lot of sense.
Our robot is not bagged, so when I can find some time to get to the bot and our driver station, I will try the pieces you suggest that require the two.

On the development computer, they are yellow. However, I wonder if moving code from one machine to another could be part of the problem. Especially, if the software is up to date on one,but not the other.

Thank you for taking the time to clean up the diagram. It is significantly more simple with the changes. You are correct that many of the conventions were due to building n frameworks to allow us to deliver a cube with sensor feedback.

The problem with auto crashing could be related to the watchdog in begin. I will make that change and let you know. It may take me a day or two before I can try these changes, but I will implement them and report back.
Reply With Quote
  #10   Spotlight this post!  
Unread 04-03-2018, 12:30 PM
JeffB JeffB is offline
Registered User
FRC #5052 (RoboLobos)
Team Role: Mentor
 
Join Date: Apr 2015
Rookie Year: 2014
Location: Austin
Posts: 318
JeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond reputeJeffB has a reputation beyond repute
Re: Teleop breaking auto with Phoenix...

Personally, I'd keep the watchdog. I've seen enough robots go crazy when there are disconnects with motors set to max/high values.

If the intent is to expand, I'd leave them where they are and let things progress if the team gets time. No point moving them inside of the loop and replicating that logic.

Yellow! That's great. But yes, different PCs might have different installations. That's why I wasn't able to tell by looking at your code. I have the newest so it wouldn't show me what's installed on your PC.

I'll look forward to hearing where things are.
__________________


Any thoughts I share are meant to be my interpretation of rules/events/intents. They shouldn't be viewed as anything even approaching an official viewpoint.
Reply With Quote
  #11   Spotlight this post!  
Unread 04-05-2018, 08:30 PM
Mr.R^2 Mr.R^2 is offline
Registered User
FRC #6762
 
Join Date: Apr 2017
Location: Hillsboro, NH
Posts: 50
Mr.R^2 is on a distinguished road
I spent a bit of time tinkering with our bot today, and cleaning up auto helped. The Phoenix vis are yellow. So, the update is not necessary. Also, it took about 3 minutes to build, deploy, and run as startup. So, that is an inprovement. In addition, the auto does now not stall even after teleop. The joystick warning is showing up in the driver station on a loop. Only in auto which is still odd, but this is a lot better. Thank you for your help.
Reply With Quote
  #12   Spotlight this post!  
Unread 04-05-2018, 11:17 PM
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,163
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Teleop breaking auto with Phoenix...

Quote:
Originally Posted by Mr.R^2 View Post
...build, deploy, and run as startup.
The "deploy" step is both redundant and unnecessary. In normal use, there is never a reason to do it. "Run as Startup" already includes transferring the compiled code to the roboRIO.
Reply With Quote
Reply


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:56 PM.

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


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi