Sample Autonomous Modes

[Tottanka]

Actually, coding wasnt the problem in navigation...
U just get the location of the bot in comparison to the light using the CMUcam2, and then u know where to turn, as in to make the gap between bot and light smaller and smaller till it reaches zero, and then u simply shoot...
The problem isnt programming, but setting the CMUcam2 correctly, which includes a lot of testings...


As of my team, we had a cannon, which was set to change his angle automatically during the game moving between 30 and 55 degrees. what gave us an awesome range...
WE just tested what angle is needed for a 3m distance,4m, 5m, 6m etc... Put it in the code beeing depanded on inputs fromc amers that sais the distance from the target, and according to it knowing the needed angle using the Gyrometer....

It really helped us, and one of my best moments in the competition was our second regional semi final when we were located 3M from ceter goal, shot 2 balls in, and then a strong but low bot pushed us all the way back to our ramp, and during his push we kept on shooting and it got in, with the cannon automaticaly adjuting its angle according to the distance...was very very beautifull...

oh yea, and Kevin is also very usefull =]

[NextPerception]

Originally Posted by Tottanka

Actually, coding wasnt the problem in navigation...
U just get the location of the bot in comparison to the light using the CMUcam2, and then u know where to turn, as in to make the gap between bot and light smaller and smaller till it reaches zero, and then u simply shoot...
The problem isnt programming, but setting the CMUcam2 correctly, which includes a lot of testings...


As of my team, we had a cannon, which was set to change his angle automatically during the game moving between 30 and 55 degrees. what gave us an awesome range...
WE just tested what angle is needed for a 3m distance,4m, 5m, 6m etc... Put it in the code beeing depanded on inputs fromc amers that sais the distance from the target, and according to it knowing the needed angle using the Gyrometer....

It really helped us, and one of my best moments in the competition was our second regional semi final when we were located 3M from ceter goal, shot 2 balls in, and then a strong but low bot pushed us all the way back to our ramp, and during his push we kept on shooting and it got in, with the cannon automaticaly adjuting its angle according to the distance...was very very beautifull...

oh yea, and Kevin is also very usefull =]

that is sort of what I had attempted to do. Our robot had adjustable shooting angle between 0 and 45 degrees freedom that was hooked up to a potentiometer. then you aimed left and right with the whole robot. what I attempted to do was make a lookup table so that if the camera was reading X on the tilt axes, it would make the shooter go to Y Degrees.
I never got it to work because at first the potentiometer wasn't working correctly and then I wasn't able to figure out how to make a PID before we had to ship the robot.

[Tottanka]

Originally Posted by NextPerception

that is sort of what I had attempted to do. Our robot had adjustable shooting angle between 0 and 45 degrees freedom that was hooked up to a potentiometer. then you aimed left and right with the whole robot. what I attempted to do was make a lookup table so that if the camera was reading X on the tilt axes, it would make the shooter go to Y Degrees.
I never got it to work because at first the potentiometer wasn't working correctly and then I wasn't able to figure out how to make a PID before we had to ship the robot.

Yea, we did the table thing to...
Only out of it we build a Linear Graph in excel, got its equation and put it in the code so the RC always knew what should be his cannon angle compared to the location of the target...

Our cannon was actually based on 2 points. one stable in the back, where the balls got into it, and annother point in the other side of the cannon, which was a gear that went up or down using a spike...
I believe it was using the Globe Motor.
we just moved one end of the cannon up and down, while the other point is stabling it... The cannon was about half a meter long, so it ddnt create problems, but if it was a 20 CM cannon, then it would have created more problems, cause then we had to make 2 moving points beeing depandanant on each other,,,and that would have been one crazy formula...

Some teams also made a rotating cannon, bout 120 degrees, meaning that they could shoot from anywhere, without depanding on their wheel position. WE didnt even try it, thought it was way too complicated for 6 members team to make...
Actually, we have even removed the X-axis servo from our CMUcam2, so it only moved up and down, and didnt move left right, which made finding the target much much faster for the camera...

Before the matches began and we suffered some bad ramming, u could actually see our camera moving along with the cannon, as if they were using the same servo (BTW thought of giving them the same servo and attaching them, but gave it up, dont remember why ).

[Astronouth7303]

Our robot last year was designed to not move, and so most of its operations were supposed to be autonomous.

Of course, there were issues that prevented this idealized vision. However, it should give you an idea of how it works.

Here's how I recommend approaching the issue. Autonomous and user mode just change where you get your inputs. They should be feeding the same routines. This allows you to use any advanced stuff you develop in both autonomous and user mode. These common routines, hardware control code, should present a fairly high-level interface. Saying that numbers are in m/s is a little excessive, but you should be getting an idea.

Last year's robot followed this, even though most of the inputs were for override modes. (And we had plans for things like power management and such. "These devices should be killed when voltage gets this low", etc.)

As for autonomous: Don't code at the lowest level you can. Instead, code at a higher level. Write functions to handle all the fancy bits. Don't implement the "drive n feet" code 5 times. You don't have to go all-out with the scripting stuff from kevin.

The single most helpful tip: Writing too many helper functions/macros is better than not enough.

[JBotAlan]

So are you saying that it is bad to have the infamous

pwm01 = p1_y;
pwn02 = p2_y;

lines that have been used in my code in the past? I'm thinking the velocity control stuff is really cool, but overkill for anything but auton.

If I did use the velocity control (which I now fully intend to implement this year) I would use a lookup table for joystick values matching to velocity settings. But like I said, that seems a bit overkill.

A little off-topic, but I have to teach a newbie this year, and I want to do some really advanced stuff. Should I walk him through it at the expense of getting it done, or do I go as fast as I can like I would if I was doing it by myself, and explain later? I just see advanced programs hard to do when I am programming to teach.

JBot

[Astronouth7303]

Originally Posted by JBotAlan

So are you saying that it is bad to have the infamous

pwm01 = p1_y;
pwn02 = p2_y;

lines that have been used in my code in the past? I'm thinking the velocity control stuff is really cool, but overkill for anything but auton.

If that was what was the interface, then it's perfectly ok. It's just sorta limiting. Something like

#define SetVelocity(left,right) pwm01 = left, pwm02 = right

is preferred for this change factor. (EDIT: Typos fixed)

If I did use the velocity control (which I now fully intend to implement this year) I would use a lookup table for joystick values matching to velocity settings. But like I said, that seems a bit overkill.

It might be overkill, but why spend 20hrs writing it for only 10s of the match?

This is especially helpful the drive motors are not symetric--they're biased.

Just one word of advice. If you get into fancy motor control loops, I recommend calibrating the victors to absolute. Subtle bugs appear when 127 - 7 drives but 127 + 7 doesn't. You can use my small program to do this.

[JBotAlan]

Originally Posted by Astronouth7303

If that was what was the interface, then it's perfectly ok. It's just sorta limiting. Something like

#define SetVelocity(left,right) pwm01 = p1_y, pwn02 = p2_y

is preferred for this change factor.

Warning to those who copy and paste, there's a typo, it's pwm, not pwn
Anyhow, if I'm going to be calling a SetVelocity function at all, I'm going to write a feedback loop, or at least a PWM output-to-velocity lookup table because it's fun to be exact (whoo, I guess my obsessive-compulsive is taking over ).

Originally Posted by Astronouth7303

It might be overkill, but why spend 20hrs writing it for only 10s of the match?

This is especially helpful the drive motors are not symetric--they're biased.

Ahh, good point. Note to self: separate lookup tables between left and right drive.

Originally Posted by Astronouth7303

Just one word of advice. If you get into fancy motor control loops, I recommend calibrating the victors to absolute. Subtle bugs appear when 127 - 7 drives but 127 + 7 doesn't. You can use my small program to do this.

Will do. I just pulled down the file, the description for it, and IFI's manual for the Victors (which I'm sure I have somewhere already, I just am not sure where. I need to get my obsessive-compulsive focused on that *mess* of a downloads folder...it clocks in at 14.7GB with 2995 files in it... )

Thanks,
JBot