Originally Posted by lineskier (Post 1036746)

The drive typically get values from 1 to -1. I was running at a .15 and .25. What I found was that with the older model battery, the robot would hardly be able to move. Where as with the newer one it would cook.
The motor speeds wouldn't change but the power would. Also our cims were geared way up. So the robot didn't have the torque to move at low speeds with an older battery. It seemed the difference between the batteries was enough to give it that extra bit of torque at low speeds.

Originally Posted by Matt Krass (Post 1036747)

Interesting, has there been any data on the electrical characteristics of the new batteries? (I admit I haven't looked, been too busy trying to get my programmers to comment their Subversion entries!)

Matt

Originally Posted by lineskier (Post 1036751)

haha. I have no idea. also it seemed only to be a problem at low speeds, but it took me all comp to figure out why the speed seemed random. Again part of it was our design... a 2 cim drive direct through toughbox (1 cim per box). In the end this setup just sucks, sucks for programming, sucks for driving. We also found the setup would essentially overheat after a minute of use on the carpet, and would just quit. Hopefully other people can learn from our mistakes.

Originally Posted by lineskier (Post 1036741)

Honestly, autonomous this year is much more difficult than last year. Plan on never capping. However, what your team need to realize, to compete this year, you need a working autonomous. Look at the finals matches from all events, they are full of robots with working autonomous. I say this, because your team needs to help you reach the goal of autonomous.

Insights I have for you from week 1. If you are running motor speed at a .1 or .2 in autonomous watch out for the batteries. The newer batteries have more power than older one's. This caused me to smash into the driver station in one match. Watch out for the coasting CIMS, if they are geared to high your autonomous will be almost impossible.

Your robot will fail epically at least once in autonomous. Try to do this on thursday, so you can learn from it.

If you have your code, feel free to send it to me mwtidd@gmail.com. I'll take a look over it, and see if there's anything you should be worried about.

If you find that the robot was poorly designed for autonomous. Just scrap the autonomous. I should have done this earlier in the comp and focused on the minibot.

Try to avoid as much blame as you can. If you get a working autonomous you will be a hero, but this is dependent on so many design factors. Its often better to let the robot sit in autonomous, and just work on getting the autonomous working on the practice field. You won't need it til saturday.

At BAE we actually organized the sharing of the practice field... we had anywhere between 2 and 4 teams sharing the space at one time. It worked really well to have 2 or 3 teams debugging their autonomous together. Its also motivating to see other working robots, and other teams having trouble. I have more fun playing in the practice area, than watching the matches :). It is the back room that the real magic happens.

Hope I helped!

Originally Posted by davidthefat (Post 1036758)

The first paragraph did not help much :p. I do not have the code with me, that also adds to my nervousness. And thanks for the heads up for the motors, I currently had it at around 40%. Man, our autonomy (actually software in general) usually gets scrapped until the end. We are the lowest priority apparently. Now I totally agree with you. Our sensors are literally going to be zip tied on or something. I constantly told the electronics, and CAD people what we needed from week one. It is not in any of the CADs. I can't believe everyone just expects the programmers to pull off miracles. So right now, we are like a blind man with a walking stick. It will be tough.

Originally Posted by Matt Krass (Post 1036761)

Traditionally programmers usually get this kind of treatment. The best plan I've seen for fixing it is to get involved in the mechanical side of things. You'll learn more skill-sets, you will be be able to personally design in and mount your sensors, and best of all, you're not 'just a programmer' anymore, so you may have better luck communicating.

Unfortunately, especially with FIRST giving out so much pre-written code (that only sort of works, not that anyone else understands that) people tend to assume the programmers job is point and click monkey.

Matt

Originally Posted by Matt Krass (Post 1036761)

Traditionally programmers usually get this kind of treatment. The best plan I've seen for fixing it is to get involved in the mechanical side of things. You'll learn more skill-sets, you will be be able to personally design in and mount your sensors, and best of all, you're not 'just a programmer' anymore, so you may have better luck communicating.

Matt

Originally Posted by davidthefat (Post 1036765)

Now, I am a very "low level" person and my mentor finds me too valuable of a programmer to be doing electronics or any hardware. I try to use the lowest to the hardware the software allows. I have just glanced over the pre-written codes, I was "appalled" by the thought of even copying the method of doing things they use. Plus, I don't like the way they do things anyway. May be that is my personality flaw, but I see it as a good thing. Might hint on the fact that I am arrogant, but shows I am independent. I have been criticized by other programmers because they think I am just making it harder on myself. I like the challenge actually and I feel guilty if I use prewritten code, feels like cheating to me. (Now it really is not cheating per se, but feels very much like it)

Originally Posted by DonRotolo (Post 1036786)

My honest recommendation is to sign up to be the "Team Scapegoat". Everything is the Scapegoat's fault, so the Scapegoat always gets blamed.

Of course, it is NEVER EVER the Scapegoat's fault. So, you can rest easy knowing it was not your fault. But only as the Scapegoat.

==

Seriously: Test your code in the practice sessions, that's what they're for. At the very worst, you disable it for the entire regional - not the end of the world.

Originally Posted by davidthefat (Post 1036758)

The first paragraph did not help much :p. I do not have the code with me, that also adds to my nervousness. And thanks for the heads up for the motors, I currently had it at around 40%. Man, our autonomy (actually software in general) usually gets scrapped until the end. We are the lowest priority apparently. Now I totally agree with you. Our sensors are literally going to be zip tied on or something. I constantly told the electronics, and CAD people what we needed from week one. It is not in any of the CADs. I can't believe everyone just expects the programmers to pull off miracles. So right now, we are like a blind man with a walking stick. It will be tough.

Keep in mind, I have been programming everyday since day one. It is just that I had been given lots of little "projects" to do. I wanted autonomy to be #1 this year, but people kept on piling on jobs to be done and it was the last thing on the other people's minds.

Originally Posted by lineskier (Post 1036741)

Honestly, autonomous this year is much more difficult than last year.

Originally Posted by Laaba 80 (Post 1036829)

If you are experienced enough to take advantage of certain sensors, this is the easiest autonomous mode I have seen. If youre not using the sensors, then I agree with you, it is considerably harder.

Dont let yourself get down if you arent experienced enough to use the sensors, or your mechanical guys decided they werent important enough to put on the robot. Success will come as you gain more experience.

Originally Posted by davidthefat (Post 1036830)

I agree, TBH, it felt as if the GDC was actually was PUSHING autonomy. They had lines and the reflective tape on the pegs (they really do stand out). Last year, it was just a circle.