galaxia5987 / robot-2019 Goto Github PK

To make the robot climb to the third level, we need to monitor the four legs to make sure the robot doesn't tip, there are several ways to do so.

1. Four seperate motion magic talons:

Each piston/leg will have its own motion magic for its talonSRX. all four of the talons follow the same path, and they will most likely go up at the same pace. (this is the simplest way to do it)

2. Two pairs of leading and following talons:

The top right and bottom left talons calculate their way up, and their adjacent talons will follow their outputs / positions.

3. Movement graph with constant checking:

All four legs set their height to follow a single graph of height by time. if one of the legs moves starts overshooting or stalling, all the other motors change their movement to lower the difference between them.

4. Use gyro to make sure the robot wont tip.

Based on the angle of the robot, we speed up or slow down the legs.

Make sure you are using the exact names of commands as they are written in other branches. Do not create dummy files because it will cause conflicts when we merge the branches (do not forget to merge master inside the new branch after all other subsystems' codes are merged into master).

When three seconds are left to the match (put this in a main constants file), the robot should:

• close Hatch Panel Gripper
• fold Hatch Panel Floor Intake to vertical position
• fold Cargo Intake inside robot
• lower the Elevator to floor level.

Superstructure, or SS in short, controls them all. It knows about all the systems, to keep each system independent of other ones. Superstructure can get all the inputs from and control all the outputs of all the systems.

Usage example

The Driver commands the robot to drive to the third level of the Rocket and place a Hatch Panel there. Superstructure commands the Drivetrain to get to the coordinate gotten from Network Tables. Superstructure checks constantly whether the Drivetrain has less than two meters left to drive to the Rocket, with information gotten from the Drivetrain. When this condition is met, Superstructure commands the Elevator to get to the height of the third level of the Rocket. When all systems reached their desitnations, Superstructure commands the Intake to release the Hatch Panel it's holding.
No subsystem in this command had any knowledge about any other subsystem.

To prevent the robot form falling we can use the navx gyro to make sure all four rods are going up at the same pace, instead of having all the talons follow the same calculations

As we have seen in training, its not that odd for a cargo ball to get stuck on the electronics of the robot. there should be a commandgroup / override which allows the wrist to rotate inwards to grab the ball.
do note that the limist switches may affect this command group, and must be checked accordingly.

The Drivetrain configuration currently written in this repository is probably that of the DrivingBot. This year's configuration is three Mini CIMs and one encoder on each side.

• remove encoders declaration, constants and ports.
• motor controller configuration to one Talon SRX and two Victor SPXs on each side, with the encoder connected directly to the Talon SRX.
• change getters of velocities and distances to Talon SRX getters.

Not a bug on our part but I thought id post it here so everyone knows.
When the robot is enabled, there are cases where the robot stops working, for exactly two and a half seconds. after talking with ari, he explained that we aren't the only team experiencing this issue.

I read this segment in the Talon SRX Software Reference Manual (page 95):

The benefits of this control mode over “simple” PID position closed-looping are…
• Control of the mechanism throughout the entire motion (as opposed to racing to the end target position).
• Control of the mechanism’s inertia to ensure smooth transitions between set points.
• Improved repeatability despite changes in battery voltage.
• Improved repeatability despite changes in motor load.

this leads me to believe that maybe it is unnecessary to create four different PID states, we could go with only two or even only one, as it will save time in the tuning phase, Needs testing.

Use this picture:

The Python program right now plots the point. What I would like to have is two arrows pointed in the direction the robot enters and exits a Dubins Path.
I think that might be pretty easy if the Python program could know what are the centers of the two circles. That's because the direction is tangent to the circle and a tangent to a circle is perpendicular to the radius which goes from the center to the tangent point. @pauloalbert, what do you think?

currently, the acceleration calculation (v - vl)/ /\t, is done using a constant refresh rate for the time, at 20ms. this can create problems in real time, and is generally better to calculate the time delta.

Create a function that prevent the robot from falling

The following steps should be taken:

• co-processor recognizes of vision target and calculating the polar coordinate of it
• Operator gets an indication that everything is set:
  • robot sees a vision target
  • robot owns a game piece (if it owns a Hatch Panel – make sure the Hatch Panel system faces the wall [you can check it with which camera out of the two sent the information])
  • reasonable measurements are sent from co-processor to roboRIO
• Operator clicks a button indicating the height level (Cargo Ship/Rocket 1/2/3)
• roboRIO creates path and follows it; raises Elevator to needed height and actuate relevant Intake.

Extras:

• create a similar command that collects a Hatch Panel automatically from a Loading Station
• make it simple for the driver to override the autonomous operation if something goes wrong.

Send this to "vision" table through the Boolean key "driving forward". This is for the Jetson to know which stream out of the two (from two cameras) to send to the driver station.

Trying to take a different approach on the method that smooths the path

If the difference between the two joysticks is less than a constant number, put the higher value between them on both joysticks.

If the robot moves to the opponent alliance side, it should:

• fold all mechanisms inside the frame perimeter
• lock all mechanisms inside the frame perimeter until the robot passes back to its alliance side.

You need to think how to implement this. @yuvalsan4545, maybe with vision? Unfortunately, it is probably too late to add sensors like ultrasonic sensors to the robot (but maybe not).

The robot should prevent itself from releasing the rope.
this is essential in both setpoints, and also in set speeds, and shouldn't depend solely on the limit switches.

not 100% sure it's that important but should be looked into
possible fix- if the dot is behind him try and declare isReversed as true to fix it.

Limit the acceleration and speed of the robot so we don't burn/destroy the motors.

This is good for you to see what great stuff you have already made, and also for future generations and generally curious people to benefit from. We'll probably write something anyway to show to the judges, so it's better to write about something at the moment you make it.

Could be a great task for a composition task in English lesson...

currently unclear how well it works needs testing

Currently the mechanism overshoots a little bit which is fine but it tries to correct the position and turns at the end

Maybe add a case point for a ccc path

This could be achieved in two ways:

• change Pure Pursuit to another algorithm / modify Pure Pursuit
• turn by angle when reaching the end
• put an imaginary further endpoint (works only if the endpoint is a wall)
• change the path to a line-curve-line
  • need to find the minimun length of the final line

add option to switch to teleop after the drivers start pure pursuit