search

Skunkworks1983 / FTC-Cascade-Effect-sandbox

Contains a hodgepodge of semi-related robot test code, FTC 1983 & 7818 can share their code snippets.
4 stars 6 forks source link

Develop an Autonomous Route that will grab a rolling goal and bring it to the parking lot. #8

Open LeoSalemann opened 9 years ago

LeoSalemann commented 9 years ago

Need a working latch first. Can probably do this without turn_degree(). Route would look something like this: drive_distance(from_ramp_to_first_goal); latch_close(); drive_sideways(half_meter_or_so_to_left); // do you don't hit the center goal or ramp drive_distance(-from_goal_to_edge_of_field); // negative value, so you go backwards drive_distance(half_meter_or_so_to_left); // a little more to the left so you land in the goal.

OrbitalObject commented 9 years ago

I think now that we have a latch design this will be easy. Do you think it would be useful to use two ultrasonic sensors to triangulate on the goals? RobotC can do this very reliably. -Cole Evans

LeoSalemann commented 9 years ago

@Zipcoaster21 an interesting idea, but will need to be prioritized with everything else. In general, one of the two robots should always be in-use by the drive team for practice. The other can be used for mechanical, electrical, and software improvements. Whenever an improvement is made to "Robot A" that bot should go to drive practice, and the change should be copied to "Robot B"

So, if there's no mechanical, electrical, or other software changes with higher priority to do, then this change could be considered. A good way to evaluate and prioritize ideas for improvement, is their complexity to implement vs. the number of points you stand to gain in competition. Seems to me the arm improvements should be done first, then perhaps some enhanced autonomous that doesn't need extra hardware and wiring such as ultrasonic sensor ... then, try the sensors. Small, frequent, incremental changes.

LeoSalemann commented 9 years ago

Okay, I just looked at Autonomous.C in the CompetitionCode folder. Yes, this is good code that did its job to get us through the first competition. But before we do anything with complex routes or ultrasonic sensors, we have to develop drive_distance(), and either turn_degree() or drive_sideways() ... maybe even both.

Once we have those down, we can write programs to travel routes, composed of sequences of drive_distance(), drive_sideways(), and turn_degree() calls. I have additional thoughts on routing, for which I will open a new issue.

But getting back to my "small, incremental steps" advice, we should proceed as follows. 1) Develop drive_distance(), drive_sideways(), turn_degree() All these should live in drivebase.c, in 1983Game

2) Develop an autonomous.c in 1983Game which cals drive_distance(1.5) instead of having a buch of encoder and motor calls.

3) When the new autonomous.c and drive distance.c are working, copy them from 1983Game into CompetitionCode

4) Develop routing code, in 1983Game See my issue "An idea for managing multiple autonomous routes"

5) Copy the routing code to CompeitionCode folder.

6) Develop ultrasonic sensor support in 1983Game, then copy to CompeitionCode folder.