Autonomous Mode for Ultimate Ascent (Screenshot/vi included)

[joecloud]

Thank you all for your quick feedback!
I fixed the Servo close, and replaced it with a set angle=0
I also changed the x-value in arcade drive to a 0.

-Aaron.Graeve: I will deploy the code Monday and see if an issue is caused by the reset causes a problem for loading the frisbee. I think I'll go ahead and build a backup fixing the pontential problem though. thanks,

-z_beeblebrox: The encoder and so on, does that work based off a sensor? Like the Allen-Bradley Rightsight? What we've discussed is getting a rough estimate of how much time it takes for the bot to reach the goal, and then allow it to fire, in labview that's how I have it set up right now. But I'd like to figure out how the sensor works in labview, and how it would interact with the drive motors, right now I'm not visualizing it. Thanks though,

-Greg McKaskle: I'm going to load up the simulator when I get a chance, thanks!

[z_beeblebrox]

Originally Posted by joecloud

-z_beeblebrox: The encoder and so on, does that work based off a sensor? Like the Allen-Bradley Rightsight? What we've discussed is getting a rough estimate of how much time it takes for the bot to reach the goal, and then allow it to fire, in labview that's how I have it set up right now. But I'd like to figure out how the sensor works in labview, and how it would interact with the drive motors, right now I'm not visualizing it. Thanks though,

An encoder is a sensor that measures the amount rotation of a shaft. By attaching one to the gearbox in a robot's drivetrain, you can measure how far the robot has driven by doing some simple math based on the gear reductions and wheel size.

I'm no expert on LabVIEW so can't explain how to program the robot to use sensors. Others on the forum should be able to help you with that.

Also, I missed that you were shooting at the one-point goal. If so, just driving a little longer than it takes to ram the wall should get you there without a problem.

[otherguy]

It's been a few years since I've worked with labview, but you should be able to easily integrate an encoder to better approximate how far you have driven.

It can literally be as simple as setting up the encoder VI (see first link below for a brief guide on using the encoder), and in the first frame of your sequence structure, have a loop which terminates when the encoder value is greater than the distance you want to travel. You can tune in your motor speeds and the distance to drive empirically.

You're not going to end up at the exact same spot every time this way, but it's going to be A LOT more accurate than time based movements. The problem with using time is that you can't account for the real world variables, like your battery voltage being different every match, wheel slippage, etc.). By adding sensors to your robot you don't have to worry about some of these variables (it doesn't matter if you get to the desired distance in 3.1s or 2.97s, you only care that you got to your desired distance).

You may also find that when sending the same voltage to the left and the right side of your drivetrain, that it doesn't drive straight. This can be accounted for in mechanical differences between each side (different amounts of slop in chains) or that the weight distribution isn't even between the sides, or that the motors themselves actually have different top speeds in fwd/rev.
To account for this you can look into adding a gyro onto your robot.

If you want to learn a few things in the off season to really help your performance in auto mode. You can give yourself a real advantage if you know how to make your robot:
- drive a set distance (encoders) and drive in a straight line (gyro)
- and turn a specific number of degrees (gyro)


Some resources:
How to interface w/ sensors in labview
FRC Mastery - An older, but awesome set of video tutorials on a large number of topics

There are is an encoder and gyro example here
And a number of good examples here

[joecloud]

Alright, thank you all so much for explaining that. We've looked into it, but I think I'm going to save it for the fall so I can use it as a tool to help teach other programming team members labview. Mainly due to time constraints.
I had the opportunity of working on the code and the robot today.
Based on the code I included above in my first post. I'm having troubles getting the autonomous mode to work correctly, when I enable it- it launches and the drive wheels do spin up- but they are doing what Aaron pointed out (spinning in place), even though I did correct the code and I did set the x-value to 0. The left wheels are going in one direction, while the right side are going the other direction, I don't recall which direction they were going in though. I do know that our begin.vi specifies that the LeftMotorInverted value is set to 'True' on the open4motor block (can jaguar).
I've tried different combinations, but if you all have a specific combination of values that should work-I will test that tomorrow. Also if there is another trick that will fix this problem that only occurs in autonomous, I'd really like to know what your thoughts are.

Another problem I've noticed is with Push1, the Shooter CIM motor, even though I set the value to '1' for Set Motor Output, it only turns on for a fraction of a second, and then winds down. It won't stay on, teleop mode works fine though. I've found a block labeled "Motor Enable" Under the same motor palette, and I currently have it included in the code, but I have not deployed it yet. Do you all think this would solve the issues? And if so, if I need to set any additional values for it besides giving it a reference and connecting the output to the next "Set Output" block? And if it isn't, what might be causing the motor to only do 1 360degree turn before winding down.


Also, as for the Feeder, and Servo 1, I have not yet had the chance to test the effectiveness of having them running concurrently, or switching them so they run separately like Aaron pointed out, but I did have to change the output values for feeder to things such as 90, and -90 (instead of '1', and '-1'), to get it to move the amount of degrees I wanted it to, (I'm not sure what kind of motor it is, but It isn't a cim motor, it acts like a large servo motor that it hooked up to a jaguar.) But anyways, both the servo and feeder are working fine.

Sorry for the large body of text, and thank you all for your suggestions! I really do appreciate it!

[Doug Norman]

To determine the correct X and Y axis motor values, one thing you could try would be to run in Teleop mode and probe the wires that go from the joystick to the Arcade Drive while driving the robot in the direction you want. This will help you understand how the X and Y values work.

For the Push1 motor (or any other output), it is expected you write an update value at least every 100ms. Otherwise the Safety Output turns off the motor. This is to avoid a run-away robot. An alternative would be to use the Motor Safety Config to disable/enable this safety mechanism - the same way you did in your drive motor code.

[joecloud]

Thanks! The drive motors are now working, I'm scratching my head about why it is working this time when it wasn't working yesterday (I did try that combination of values before). But now it is set up and moving forward properly.

I'm still having issues getting the Push motor to stay on, It spins up for about a second before winding down.
I did include the Safety config block, the problem might be that I'm not configuring it right though? Do I need to set values? I included a screen shot of what it is like at the moment. I do have the mode on the block set to disabled, but that's it.

Any tips are sincerely appreciated!
Thanks!