Autonomous Mode for Ultimate Ascent (Screenshot/vi included)

[joecloud]

Hey guys, so I've been testing out Autonomous mode (haven't had a chance to deploy it yet). But the main thing I'm trying to accomplish is learn how to use that tool- Since we didn't use it during the Ultimate ascent competition. But I'm not sure if the code is right, I drew it as what I thought would be a logical manner- But I'm still learning, any tips/feedback is appreciated.
It is designed to shoot at the 1 point corner goals. My intentions with the code is as follows:


-Robots moves for 3 seconds towards goal. and the main shooter motor spins up during that time.
-Robot stops, note: shooter motor (Push 1) will spin until the entire program is done.
-Feeder (arm motor that will push frisbee forward into Shooter motor) will move forward moving frisbee forward.
-Feeder arm retracts, Servo 1 (it acts as a gate, so frisbees can't drop into loader until the loader is empty) opens, allowing frisbees to pass.
-feeder arm pushes forward again, launching frisbee #2. while servo 1 returns to original block position.
-Feeder arm retracts, Servo 1 opens, allowing frisbee #3 to pass.
-Feeder arm pushes forward frisbee to Push 1 motor, which launches frisbee #3 into goal.
-Everything terminates.


I attached a screenshot in this post of what it currently looks like.
As well as the vi itself.


Thanks guys,

[Aaron.Graeve]

Just looking at it briefly, it seems your drive forward would actually drive in an arc either left or right, depending on your mechanical setup. This can be fixed either by using Tank Drive, or by changing the x-value to 0, so no turning occurs.

Secondly, your fire/reset code looks to be fine; however, you may run into an issue that you need to actuate the arm motor and the servo at different times due to the nature of your loading mechanism.

Thirdly, it is worth pointing out that the servo may have ambiguous behavior at the end of autonomous. I do not recall off hand whether the ServoClose resets the servo or just cuts the output. You may need to set the position at the end to reset it, if that is what you want.

I am not seeing anything else, but I may have missed something. I would advise talking to someone from 33, as their code is insane and they are brilliant with LabVIEW.

[z_beeblebrox]

Unless the robot runs into something at the end of the driving, it is likely to be inconsistent in the distance it drives, possibly enough that the discs often miss. Perhaps consider using an encoder on the drivetrain and some form of closed-loop control (PID or something as simple as "drive until the encoder reaches a certain count").

[Greg McKaskle]

Just to add a bit to the other posts. You most likely do not want to close the servo at the end of autonomous. Once closed, it will not work unless reopened in teleop. You are leaving the other references alone, and you likely want to do the same for the servo.

You may be able to test out some of this using the simulator. The servo and motor for shooting will not be controlling anything, but the error with the arc instead of straight line would be pretty obvious when viewed in the simulator. Some of the other values you can chart or observe using probes or dashboard.

Greg McKaskle

[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!