Piggie Plotter: Changing the very nature of Autonomous Mode

Team 1902, Exploding Bacon, would like to present our newest project:

Piggy Plotter
http://i.imgur.com/Hsvy9lT.png

Overview:

Piggy Plotter is a GUI-based Autonomous mapping program developed completely by team 1902 during the 2015 build season. With Piggy Plotter, you can design an autonomous on a completely to-scale replica of the Recycle Rush field. You can create a robot, configure it’s starting position and size, and then set up commands to drive to certain locations and to perform specific actions. When you’re done, you can export the autonomous to a .auto file and use it as your autonomous!

http://i.imgur.com/wbgASVN.png

How does this work?

Now, by this point you must be saying/asking “How do this actually get used as an autonomous?”. Allow me to explain: when you’re done designing your autonomous, you can export it to a .auto file. The .auto file contains all the information on what your robot needs to do for your auto to work. Here is an example of a very simple .auto file:

drive:10:10]turn:180]lift:1]wait:2]lift:0]

This is where YOU come in. All you have to do is write code on your robot to be able to read .auto files and do what they want you to. For example, a team would have to implement some way of getting their robot to be able to move X number of inches. Once they did that, the robot could read the .auto file, see the “drive:10:10]” command within it, and drive 10 inches forward. Don’t worry if you have no idea how to take a .auto file and read the data from it; we’ll help you! All you have to do is ask.

Piggy Plotter, with the exception of drive and turn commands, allow you to name your commands whatever you want, in order to simplify the implementing of .auto file processing. For example, you can have Piggy Plotter do a “herpDerp” command and then write code on the robot for processing a “herpDerp” command.

http://i.imgur.com/vxLfaUv.png

Our dream for Piggy Plotter.

Team 1902 hopes that, in the future, Piggy Plotter will change the very nature of how Autonomous Mode works. Instead of teams laboring over one or a few autonomouses, new autonomouses will be able to be created on a whim at competitions. This will allow autonomous to be more about strategy and less about being a large programming hassle. Imagine a match at Einstein where an alliance comes around their alliance captain whom has Piggy Plotter on a tablet and is plotting out three brand-new autonomouses, all of which strategically work together. Imagine being able to change your autonomous to work around another team’s autonomous without simply disabling your autonomous all-together. Imagine you (or your programmers) not spending all their time fine-tuning an autonomous just for it to become unneeded or need to be heavily changed. Imagine that you can create a new autonomous whenever you want and know that it will work the first try. This is our dream.

When can I have it?

Piggy Plotter is currently in a closed beta. Team 1902 plans to test, debug, and use Piggy Plotter at the Georgia Southern Classic Regional, the Orlando Regional, and (hopefully) St. Louis. If everything has gone smoothly, we will release a more polished version of Piggy Plotter right after Championships. Once we’ve released Piggy Plotter, we will release an official field file for each year’s FRC competition.

I have a question/suggestion/comment.

Say it! This is a program we plan to share will all FRC teams, so we want your input! Other team members and I will try our best to answer your questions, reply to your comments, and implement your suggestions (if they’re valid, of course).

When you are ready to move to open Beta, we would be interested in working with you.

I can’t say guarantee anything about this right now, but I can say that this is a total possibility. I’ll let you know more when we’re closer to Champs.

I MUST remember to find you guys in St. Louis! I’ll be a CSA, and would love to tinker with this a little and see what you’ve got for code to handle this.

Perhaps you could “perfect” a class or vi to handle reading this format and opensource that as well!

We will definitely try and release some open-source files to help with reading the data; it will make the implementation process even easier! :slight_smile:

This is incredible. Does it take encoder inputs to get distance traveled, or can you set up time intervals?

Piggy Plotter just measures the distance in inches; when it comes to implementing driving X inches on the robot, we used the following formula to calculate what the encoder value would need to be in order to move X inches:

inches / (Math.PI * wheelDiameter) * (whatever encoder value equals one rotation)

However, you can implement it however you want. So that means you can use encoder values, time intervals, or anything else that works.

Will teams also attending the Georgia Southern Classic be able to come see it at your pit?

Of course! Stop by any time! Can’t wait to see you guys there, always love your robots.

This seems like a nice piece of software (Or is it metasoftware?).

A few questions:

Does it (at this point) support a way for the robot to drive non-linear paths (such as those generated using splines)?

Also what does the drive code assume about the drive base? Is it only for tank drives, or does it support holonomic robots? Does the drive base need a gyro?

Can you show the GUI for the robot creation part, where all the solenoid and PWM ports are assigned?

That sounds like a nightmare. Every automode should be tested before seeing a playing field, especially before Einstein, even if you’re combining pieces of code that have all word previously separately.

Piggy Plotter outputs an angle and a command to drive X inches, so you can do whatever you want with that data.

No drive code is assumed; Piggy Plotter tells the robot what it needs to do (i.e. drive 10 inches then turn 90 degrees), but it’s up to you to actually write the drive code itself.

Robot creation in Piggy Plotter doesn’t use or need port IDs; it generates a file that says “Hey, robot. Drive ten inches, turn 50 degrees, and then ‘setLift 0.5’.” It just gives you commands and command arguments. In your code, you’ll just write handling code for things like “setLift 0.5”.

The idea is that the way this is set up is that the to-scale field used in Piggy Plotter combined with a good programmer’s implementation of the .auto files will result in a world where you could (in theory) load a new autonomous that has never been tested, yell “YOLO”, and have it work. I agree, though, that you should test it if you can.

This seems really cool! It looks like it makes autonomous creation pretty fast. Going along these lines, something we did this year is create a recording software where the driver movement is recorded as an autonomous

Recording driver input for autonomouses is another great way to be flexible with autonomous; I look forward to seeing how yours performs! :slight_smile:

Update! We successfully used Piggy Plotter for our autonomous on the last day of competition at the Georgia Southern Classic Regional. We were able to design an autonomous that assisted our alliance partner’s three-tote autonomous, run it on the field without any previous field testing, and have it work! In addition, we were interviewed by GSCR’s GameTime crew about it! Piggy Plotter is on-track to release directly after Championships; if you want to see it in action, come visit our pit at the Orlando Regional or at Championships.

This looks like a good candidate for the Excellence in Engineering award.

Good job guys!