Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   NI LabVIEW (http://www.chiefdelphi.com/forums/forumdisplay.php?f=182)
-   -   There are things I don't know... (http://www.chiefdelphi.com/forums/showthread.php?t=114846)

tcjinaz 10-03-2013 23:00
There are things I don't know...
 
2 Attachment(s)
Howdy

I tried to move drive motor control from TeleOp to PeriodicTasks, by sampling joystick data in TeleOp, pushing it to globals, then reading the globals in the periodic loops. Terrible results, laggy response, Y-axis data got around to working, X-axis virtually ignored.

With probes in place, I can see the data getting to the Arcade Drive instance, but the outputs were junk, moreson on the X-axis than the Y. I really thought a ~20mS loop shoveling data asynchronously to a 10mS loop would be no problem.

TeleOp and Autnomous VI fragments attached. Any thoughts?

TIA,
Tim

Mark McLeod 10-03-2013 23:17
Re: There are things I don't know...
 
Why don't you just read the joysticks directly in Periodic Tasks like you are already doing for button 1?
The Globals seem to add a completely unnecessary step.

I'd pull the Joystick Refnum outside the While loop. No reason to keep doing that over and over.

Greg McKaskle 12-03-2013 07:52
Re: There are things I don't know...
 
I agree with Mark that going through the globals is not necessary and not necessarily the safest way to write it, but what you have shown should also work fine.

Can you be more specific about what the variable values were? Were they junk as in they were lagging or in that they were garbled? One thing that may be handy would be to plot them on a chart on the front panel in each location. That will change the timing a bit, but will help determine what the relationship is.

My suspicion is that something else is writing to the globals in another location. Right-click and Find will help locate them.

Greg McKaskle

tcjinaz 13-03-2013 00:58
Re: There are things I don't know...
 
Thanks for the help. I have learned a few things

a) comm data from the DS is latched. This pushes more code out of TeleOp and nto PeriodicTasks, which seems like a good thing

b) The robot project remembers too much - on the Dashboard in Test mode, I saw old and new motors after I had changed the names. Blasted the build directory, old refs went away.

c) I see good axis data (after eliminating the globals) going into WPI Arcade Drive, but the wrong stuff out. I am beginning to suspect that Arcade Drive and Tank Drive cannot coexist on the same hardware connections at the same time. Tomorrows testing will probably reveal that ya cannot switch between Arcade and Tank on the fly.

Owen Makin 13-03-2013 01:46
Re: There are things I don't know...
 
I can't tell what you are trying to do? Autonomous? regular tele-op?

Greg McKaskle 13-03-2013 07:08
Re: There are things I don't know...
 
I marked my comments with **.

a) comm data from the DS is latched. This pushes more code out of TeleOp and nto PeriodicTasks, which seems like a good thing

** During autonomous, joystick and cypress values are latched to retain the last value of the disabled period. Additionally, it is possible to read joystick and other data multiple times from anywhere in the program you want. To me, this doesn't push code out of teleOp, but it does allow you to place it in Periodic.

b) The robot project remembers too much - on the Dashboard in Test mode, I saw old and new motors after I had changed the names. Blasted the build directory, old refs went away.

** SmartDashboard doesn't have a way to delete variables, so if you were to leave it running and change the robot code to have new SD variables, it would show old and new until you restarted the dashboard. But there shouldn't be any need to rebuild or blast.

c) I see good axis data (after eliminating the globals) going into WPI Arcade Drive, but the wrong stuff out. I am beginning to suspect that Arcade Drive and Tank Drive cannot coexist on the same hardware connections at the same time. Tomorrows testing will probably reveal that ya cannot switch between Arcade and Tank on the fly.

** I still don't understand what was wrong in the first place. Globals are thread safe and are perfectly fine for asynchronous transfer of data provided you don't cause your own race condition by having multiple writers that aren't coordinated. Arcade and Tank simply perform different math on the axis before updating the motors. Plenty teams use tank for TeleOp and Arcade for Autonomous. You should be able to open a 2 or 4 motor DriveSet and use either arcade or tank on it at will. They have no effect except to update the drive motors.

Greg McKaskle

tcjinaz 14-03-2013 00:03
Re: There are things I don't know...
 
Quote:
Originally Posted by Owen Makin (Post 1247487)
I can't tell what you are trying to do? Autonomous? regular tele-op?
I appreciate the attention to the problem.

I was trying to set up the drive motor nanny in Periodic to be agnostic to the source of its inputs. Thus, globals set in Autonomous or Teleop, read in Periodic. There seems to be something weird about how I get to this point that messes things up.

tcjinaz 14-03-2013 00:18
Re: There are things I don't know...
 
Thanks Greg! Help from deep inside is appreciated (I finally looked you up :)
I'm at ***
Quote:
Originally Posted by Greg McKaskle (Post 1247516)
I marked my comments with **.

a) comm data from the DS is latched. This pushes more code out of TeleOp and nto PeriodicTasks, which seems like a good thing

** During autonomous, joystick and cypress values are latched to retain the last value of the disabled period. Additionally, it is possible to read joystick and other data multiple times from anywhere in the program you want. To me, this doesn't push code out of teleOp, but it does allow you to place it in Periodic.

*** With my thought processes, it moves stuff around. I though I had to trap the data when a teleop packet arrived. What I meant by latched was the last arriving data is available until the next update from wherever.

b) The robot project remembers too much - on the Dashboard in Test mode, I saw old and new motors after I had changed the names. Blasted the build directory, old refs went away.

** SmartDashboard doesn't have a way to delete variables, so if you were to leave it running and change the robot code to have new SD variables, it would show old and new until you restarted the dashboard. But there shouldn't be any need to rebuild or blast.

*** It wasn't the DashBoard build that I blew away, but the robot project. I will run some experiments in two weeks to see if I can reproduce.

c) I see good axis data (after eliminating the globals) going into WPI Arcade Drive, but the wrong stuff out. I am beginning to suspect that Arcade Drive and Tank Drive cannot coexist on the same hardware connections at the same time. Tomorrows testing will probably reveal that ya cannot switch between Arcade and Tank on the fly.

** I still don't understand what was wrong in the first place. Globals are thread safe and are perfectly fine for asynchronous transfer of data provided you don't cause your own race condition by having multiple writers that aren't coordinated. Arcade and Tank simply perform different math on the axis before updating the motors. Plenty teams use tank for TeleOp and Arcade for Autonomous. You should be able to open a 2 or 4 motor DriveSet and use either arcade or tank on it at will. They have no effect except to update the drive motors.

Greg McKaskle
*** I am working slowly through transforming a "base arcade" project into where I ended up in trouble, testing far more often than I could before (the proto-robot is spending spring break in my living room). Today the input reads and motor control with style switching moved from Teleop to Periodic, and so far are behaving. Slightly different from the bad path (far fewer globals), but hopefully arriving at something we can use effectively next week.


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

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