StangPS Presentation Released

[Frank(Aflak)]

I have only one question. When you get bumbed and the controller compensates. What if the wheels slide? Or it you rotate at greater than the max rot. veloctiy of the gyro? Im assuming that your program cannot compensate for that, but if it can I would love to know how. It seems a magnetic sensor would be much more failsafe than the gyro.

Still, I love what you have done.

[Dave Flowerday]

Originally posted by Frank(Aflak)
I have only one question. When you get bumbed and the controller compensates. What if the wheels slide? Or it you rotate at greater than the max rot. veloctiy of the gyro? Im assuming that your program cannot compensate for that, but if it can I would love to know how. It seems a magnetic sensor would be much more failsafe than the gyro.

If the wheels slide or we turn faster than 75 degrees/sec we cannnot compensate. However, as I mentioned this hasn't been a problem at all. As for the magnetometer, we spent a ton of time looking into using one and determined that it was not workable. There was just too much magnetic interference from all the metal and the motors in the robot.

We did some practice runs at home where we put as many bins in front of it as possible which caused the robot to get turned about 90 degrees. It didn't matter, though - it just drove up the ramp sideways! I should see if there's some video of that somewhere. It won't behave like that anymore because since then we've implemented something we call "theta correction" which keeps us oriented correctly on the field at all times. Some of you may have noticed that when we ran our "sweeper" program - the robot would appear to be twisting as it diagonally crossed the scoring area. That was caused by our drive train twisting the robot and then our software detecting that and correcting for it.

[Dave Scheck]

Originally posted by Foley350
A white paper on the wiring/ how wilddraw works would be cool

As Mike said earlier, we will put out as much information as we can once we all get caught up with real work.

Before WildDraw was complete, we had to create waypoints manually. Since we have a 2 inch resolution, we made a grid of tape on the carpet of our field. We would then locate the tape that we wanted to drive to and figure out its coordinates.

With WildDraw in place, we were given the freedom to create waypoints without being at the field.

It also gave us the ability to easily and accurately modify existing programs.


[Edited to clarify sweeper program]
As soon as we found out that the Thunder Chickens had picked us at the Midwest regional, we sat down and drew out a program that would drive to common placement points of human player stacks with the intent of knocking them down. We call this the sweeper program.

After we ran it the first time, we saw that we had missed a critical placement area, so before the match was even complete, we adjusted some points and had a new program to download as soon as the robot came off the field. The next time we ran it (which happened to be a practice match at Archemides), all human player stacks were eliminated.

On a side note, those of you that were impressed by the sweeper (including me) will be happy to know that there are some more innovative programs in the works for offseason competition. We're not going to give out any details, so you'll have to see it to believe it.

[Mike Soukup]

Originally posted by Abwehr
I have to ask this...did the team's students ever actually have a part in any of this? No offense is meant, I'm just curious...this is the sort of system that NASA would be proud of.

I can expand on the student involvement in the RC because that's what I worked on. After the team decided to create StangPS I drew a diagram for the overall architecture of the RC code - inputs & outputs of each subroutine, calling order, etc. I then started with a blank whiteboard and stepped through the design process with the students, asking them for input where they could help and telling them what I was doing when they didn't understand. Next I divided up the subroutines among the students and over the next couple of evenings they each worked on their part while the engineers floated around, helping when anyone got stuck. Then we all sat down and copied the subroutines into the code and held an informal code review to make sure it all looked good. Finally we tested the code using RoboEmu (thanks Rob, the tool allowed us to run some important unit testing and helped us be confident that our code worked) and a unit test driver that a student wrote. Then it was on to testing and debugging with the real robot for the next couple of months. So I guess we took the students from the initial design phase through coding & unit testing, all the way to system integration and deployment. An entire software cycle in 3 months.

All this time another group of engineers & students was debugging the communication between the RC & CC while another group was playing around with the gyro & wheel encoder.

To expand on what Dave said about theta correction... Because of the differences in turning rate of the crab modules on our prototype, during our initial testing up the ramp the bot always rotated when it made the first turn. By the time it reached the bins it was usually 45-90 degrees off. Steve (engineer) and Matt (student) played with the code for a few days but came up with a routine that rotates the robot and seeks a specified orientation. We played around with setting waypoints at 45 and 90 degrees off our starting position just to see it rotate as it travelled across the field. We went so far as to shove the robot while it was running in order to purposefully knock it off orientation & course and it recovered almost perfectly.

Here are some videos of our theta correction progress:
- no theta correction
- with theta correction
- theta correction test

I really wish I took video earlier on so everyone could see our many failures and milestones & see how far we came.

[ntroup]

Originally posted by Mike Soukup

- theta correction test

For the record, that was me trying to skew the robot to some other angle than its starting angle. Basically, we wanted to verify that if the robot was to be skewed, either by bins placed in front of it, or by it colliding with another robot, that the robot would:

A) Compensate for the change in angle, and 'Theta Correct' back to its pre-programmed angle

B) Not lose its position on the field during a collision and still find its way to its next waypoint.

I think the video shows pretty well that it worked as designed.... Although, I think I should have used more than just a bin to try to stop that thing. It hurts when it runs into you!! I think this was the one test trial that didn't involve parts of the robot running over my ankle

-Nate

[Warren Boudreau]

Mike S., I am in awe that you got 5-6 software engineers and what seems to be about a dozen students together on such a huge undertaking and pulled it off in 3 months.

If I might ask one question. When did you guys come up with this idea?

I hope that I can use you and your team as an example of teamwork in software development for next years team .

[Mike Soukup]

Originally posted by Warren Boudreau
Mike S., I am in awe that you got 5-6 software engineers and what seems to be about a dozen students together on such a huge undertaking and pulled it off in 3 months.

If I might ask one question. When did you guys come up with this idea?

I hope that I can use you and your team as an example of teamwork in software development for next years team .

Thanks Warren, it was quite an undertaking. By by no means was I incharge of the whole program. Steve Tine was in charge of the autonomous system; he kept us on schedule, designed the circuit board, and wrote some of the RC code.

We had 5 software engineers working on all aspects of the system - RC, CC, & WildDraw. We didn't have 12 students though. About 5 or 6 were involved with the RC programming and 1 more helped with the CC, but we did have some spillover and 1 RC student helped with the CC.

I don't really know when we came up with the idea. It's all I remember ever hearing about so I think it was early on. We knew we wanted a really strong autonomous mode that was easy to configure and change on the fly, and was capable of following complex paths. We knew we had the resources and knowledge to get it done so we gave it a try. I think Steve & Raul came up with a lot of the early ideas to use a positioning system.

Feel free to use us as an example. If you need any more info feel free to contact any of us and we'll help you out.

Mike

[Al Skierkiewicz]

Warren,
You might remember that there was a lot of talk going around during Lego League season (last fall) that autonomous mode as used in Lego League would be a natural for inclusion in FIRST competition. With all of that conjecture it became a matter of discussion among many team members that we should start to think what it would take to run auto. A decision was also made that if we were going to do it, we were going to have to make it work very well. When the game was announced, we were already committed to having an auto sub team and many of those members had worked with Lego League and had that experience to draw from. With so many working on it, there were a lot of ideas that were tried and cast aside in the first weeks. (electronic compass, magnetic heading, stress gages for direction and attitude sensing and gyro for rotation) The StangPS team could only get at the robot to test after practice and build, and usually for only short periods of time. But they were a committed bunch and they made it work.