WPI1 Reveal

Here is a reveal and explanation of Vex U team WPI1’s completely autonomous robot that we competed at worlds with. We did about as well as we had hoped, winning one match and being competitive in around five others. Thanks to all the people that came up to our pits asking questions or taking a picture with us after a match. I was happy to see that people are interested in advanced programming and liked the idea of a robot driving itself. I can certainly say that I much preferred the robot drive itself, it makes for a much more relaxed match!

We have made all of the code public and put it into an organization on GitHub: https://github.com/Team-Optimistic

There are five repos, four of them (robot_driver, goat_lidar_merging, motion_path_creator, and xv_11_laser_driver) run on our Raspberry Pi and the other one (Team-Optimistic) runs on our Cortex. Here is a short explanation of what each one does:

Team_Optimistic
This is the only one that runs on the Cortex. We are using the latest RobotC with my library BCI. This code handles communications with the raspi, closed-loop control for all the motors, navigating to points specified in the field frame, and picking up objects at points in the field frame.

robot_driver
This is the main ROS node running on the raspi. Its primary job is to handle comms with the cortex, but it also publishes ROS messages to the EKF node and our other nodes.

goat_lidar_merging
This node (GOAT) collects LIDAR messages from XV and runs a PCL clustering algorithm on that data. It publishes two lists of big and small objects to MPC.

motion_path_creator
This node (MPC) accepts lists of objects from GOAT and our estimated state vector from the EKF and determines the best object(s) to pick up next, then publishes this path to robot_driver.

xv_11_laser_driver
This node (XV) interfaces at a low level with our Neato LIDAR. It accepts incoming packets over a serial connection and constructs them into a ROS LaserScan message which we can transform into different frames.

There is too much code here for me to give a detailed rundown of each function and all the control flow. Please post questions down below, as specific or not as you want and I will try to answer them as best I can.

3 Likes

video of it doing its thing?

We didn’t end up taking many videos, but we do have this one

Here is a video of it while under development.

Here is a video of us comboing multiple stars. This was the second test of that functionality at all so it improved since then.

2 Likes

Here is also one of the matches I filmed. I can’t for the life of me figure out why 1080p looks so trash

2 Likes

This was legendary. Well done for getting it to work :slight_smile:

1 Like

Amazing!
Think this is the closest thing to having AI for a Vex match.

2 Likes

What were all the sensors your robot used and what were they used for?

80$ Lidar used for mapping the field
IMU runs into the pi
VEX encoders run into cortex and are sent to pi

Pi puts together IMU and encoders to great a position estimate on the field. This estimate was so good the robot could run continuously on the field for 5+ minutes.

2 Likes

But how about the sensing of the game elements and also the decision making (ie. which pile of stars to pick up 1st) ?

Is the precision of the position estimate still be good enough in a full open field? If it is, then maybe it will work better for this season game :slight_smile:

1 Like

The position estimate was actually spot-on, even after driving around for 5 minutes scoring and bumping into the fence. Localization might be easier this year, but the rest of the game is much harder to do autonomously.

Decision making was done by calculating the cost of each object on the field, and then selecting a path which minimized the cost of scoring. Higher point objects were less costly, so we often sought out cubes over stars. Sensing game elements was done by collecting lidar points and identifying clusters over a certain number of points as either stars or cubes.

This is really interesting. And it really reminds me of those long-ago days when the only robotics competition around was the micromouse :stuck_out_tongue:
The decision making approach is very similar to how the mouse decides on which path to take.

Do the program plans the path 2 to 3 steps in advance or it is one step at a time?
I know the game changes so fast that most of the time it doesn’t make sense to plan ahead, but maybe by planning ahead, it might allow the robot to anticipate the opponents’ next move :slight_smile:

I should have gotten my programmers to drop by your pit and learn something from you guys.

1 Like

I should have dropped by, too. I had no idea about this thing at worlds even though it was right next door :stuck_out_tongue:

We plan a single dump. That can be multiple stars comboed together or a single large object. Or a combo of stars that ends in a large object.

This is a little late, but have you thought of putting a sensor in the claw to detect if it grabbed anything? It seemed to grab nothing a few times and think it had something and proceeded to dump nothing.

Ya it had not had too much issue in testing and at worlds we all agreed it would have been a good idea.

Wow! Are you planning to do fully autonomous design for the ITZ season?

If yes, count me as one of the team WPI fans and, please, keep us posted about your progress!

Why didn’t you guys get think award?

This is a unique, well-thought out solution I’m sure took months to perfect, and as far as I’m aware there wasn’t another team at worlds that had a fully autonomous robot like this, let alone a fully autonomous robot that actually won against another team’s driver control and autonomous. Team WPI1 is pioneering a new definition of what VEX autonomous robotics should be, what on earth kept you from winning Think AND Innovate?

So ya we got the create award for “creative engineering solution” if memory serves. The entire robot was mechanically designed to maximize the field of view of the sensors as well as to facilitate odometry. So we did have a lot of creative and different engineering solutions. So the people on the team that worked on the mechanical design were rewarded. The people that worked on the software, which took 1000s of hours and was the highest level software ever run on a vex competition robot (probably) did not get an award.

I believe it was because of the recommendation RECF makes that says that judges should avoid giving a team multiple awards at an event. I think it is more inspiring to celebrate teams that go above and beyond and to recognize amazing work than to give 2nd or 3rd place awards. If another team had something 90% as sophisticated I would have gladly let them get the award and have taken them out to dinner to talk shop. Anything less I don’t think it is right to spread the awards out.

I see a team get 4 awards at a local event and wonder what I can do to be like them someday. When I see 5 teams that had kinda half-assed stuff win awards instead it makes me care about the awards less.

@Tarek Shraibati might be able to give some insight