Learning Autonomous Mode?

[JohnFogarty]

yeah, that would be the idea to drive it while recording encoder data. The take the encoder data to make the autonomous. Our Palmetto Regional Kicker device was a motor Kicker Paddle wheel sooo we could have used it there. But yeah if only I had a clue how to begin trying this.

[mwtidd]

Originally Posted by John_1102

The take the encoder data to make the autonomous.

From the video, it looks like the issue occurred during the rotation. The encoders would have the same issue as they would have different slip each time. If I were to try it I would hook up a gyro and 2 joysticks, one for going straight, one for rotation (just so you don't do both at the same time) Driving straight could be by the joystick, and then any time you rotate the code could reference the gyro values. Also by doing it this way, the robot could probably accomplish the task faster as you could speed up the rotation period.

Also by using the gyro, you could also make sure that straight was actually straight.

The encoders may be a good idea for the straight period though, as long as there is not too much slip. For going straight, if you have a reference point, a rangefinder may work well too. Allowing the robot to speed up the process faster than a driver could.

I believe that wheel slip is the most variable thing in autonomous. So I would tend to lean away from anything dealing directly with the wheels (ie encoders, js values)

[Tanner]

Originally Posted by John_1102

Tanner! Are you saying you made program that basically records what you do while driving it? Then you go back and have the robot and do it on it's own? Like a record/replay sort-of thing? THAT sounds awsome! May i get a copy of the code to look at??

Yeah that's pretty much what it does. In the LabVIEW vi's I actually have a giant "record/replay" button.

The code is actually on a desktop computer at the school, so it'll be a few days as I need to bring that computer home.

Originally Posted by lineskier

From the video, it looks like the issue occurred during the rotation. The encoders would have the same issue as they would have different slip each time. If I were to try it I would hook up a gyro and 2 joysticks, one for going straight, one for rotation (just so you don't do both at the same time) Driving straight could be by the joystick, and then any time you rotate the code could refer to the gyro values. Also by doing it this way, the robot could probably accomplish the task faster as you could speed up the rotation period.

Also by using the gyro, you could also make sure that straight was actually straight.

The encoders may be a good idea for the straight period though, as long as there is not too much slip. For going straight, if you have a reference point, a rangefinder may work well too. Allowing the robot to speed up the process faster than a driver could.

I believe that wheel slip is the most variable thing in autonomous. So I would tend to lean away from anything dealing directly with the wheels (ie encoders, js values)

Though the robot did run into a trashcan, which is problem caused because of trying to align the robot with no markings on the floor. The slick wheels probably aren't helping the situation either.

As I said in a earlier post, the robot wasn't outfitted for sensors, so I didn't use them. If I had them on the robot, I would certainly have chosen those over the joystick values. If I have time this summer, I might play with this year's robot which has a few sensors on the drivetrain which I could use (plus no more of those slick wheels - yay).

I'm not sure how you would get around the wheels slipping without some sort of positioning system.

It works good as long as you can get the robot aligned in the right position every time. With my team's robot, we probably would've used this system for this year and last year. Both had really simple autonomouses.

Cheers
-Tanner

[apalrd]

When driving straight or in arcs the wheel slip should be negligible. When turning sharply it is different, but then the gyro is preferred over the encoders.

Story time: Back at Kettering (week one), I had no feedback on speed during autonomous. It had no compensation for drift, it just drove at X speed for Y distance and kicked. It was not reliable. After the competition, I tuned feedback to speed on each side. It now drove straight and had no issues of not moving when the battery was low. Use sensors. They make life easier.

[ayeckley]

We implemented this type of system this year. I'm trying to find time to write a white paper about it soon.

[mjcoss]

We implemented a recording system for our robot this year. It is written in C++, as well as in Java. The main reason was to allow us after a match to review what happened out on the field. So we captured all user and senor data, and stored it in a text file. After implementing the recorder, we verified that it had minimal impact on the run time behavior of the robot. Each record contains a timestamp, and is written only when the user inputs change. There's plenty of flash disk space, so this was never a problem. But a match would have 1000's of records.

With the recorder in place, we then proceeded to write a replay function. The file can be read, and the data used to replace the users specified actions. For the first version of the code, we simply ignored the sensor data. This, as has been pointed out, leads to the robot not quite doing the exact same thing every time. Without sensors, you are using time as a means of controlling behavior. 3 seconds forward, 2 seconds back, etc. Since the mechanical system has quite a bit of variance, this isn't particularly accurate. This can be enhanced by using the captured sensor data. Say you have a gyro, and you record the gyro data. Then during replay you can compare the current gyro data to the recorded data, and if they aren't the same (within some epsilon), you adjust the movement of the robot to compensate for the drift.

Finally we then had our driver, do what we wanted for our autonomous mode. Pulled the file off the CRIO, cleaned it up a bit, and then saved it on the CRIO as autonomousXXX.txt. Then all our autonomous code did was read a switch that indicated what autonomous file to run, and opened the file and replayed it.

At the end of the day, there is a lot of uses for the record data, above and beyond just finding out what the robot thought it was doing out on the field.
Some that are on our todo list:
1) Macro actions, saved as files and replayed.
2) Creating a simulation so we could replay the files and see what happened during the match.

---Michael J Coss Lead programming mentor for team 303

[mwtidd]

Originally Posted by mjcoss

We implemented a recording system for our robot this year. It is written in C++, as well as in Java.

I'm wondering if you would be willing to contribute this to the Bobotics ADK or open sourcing it so I could? This is one tool I'd like to provide to all teams.

[mjcoss]

Sure. It needs cleaning up, and as I said, it right now just replays joystick data and ignores the sensor data. I really wanted to make it a bit more flexible with regards to the data capture (what get's capture, and when), and how the replay works. It's going to be my summer project.

---Michael J Coss