Originally Posted by Bethie42 (Post 1037099)

Here's another nervous programmer :D

I was writing autonomous mode at 9 PM on robot ship day. And shrieking when the line-following worked. And then rewriting autonomous almost completely so that we'd score as soon as we reach the tape-line T, not just overshoot it and ram the driver station as happened at our Week 0 event. And then we had to bag the robot. So autonomous never got fully tested.

Besides programming an autonomous mode that is going to have to be extensively tested and probably reworked, I am in charge of scouting, Chairman's, and am also team captain [I'm the only non-rookie student on the team]. I love my job but having code to write, hardware issues to keep an eye on, troops to marshal [ ;)], feisty limit switches to debug, matches to scout, judges to interview, and new students who are enthused but have no idea what they're doing who need to be briefed about EVERYTHING before the event.....I'm panicking just a little.

I suggest you make a list. [And probably another list, and another...] I've got loads more stuff to plan than you do [hopefully], but I find making a list of things that could go wrong and need to be fixed, things that have to be done as soon as you get to the event, things to check as the event goes on, etc is a good way to both calm your mind before the event, and be a lot more efficient during the fracas.
Also, there is no reason to be nervous about an FRC event unless it's your last year...like it is mine...enjoy it while you can. Good luck!

Lineskier, that is good to know about the .1 or .2 motor value/battery issue. I have a related question which should probably go in the programming forum but I'm going to stick it in here:
Our autonomous mode [the only place we feed a value directly to the Victors, as opposed to taking the value from joysticks] involves tank drive, going straight forward and turning [to correct if we've left the tape line]. I'm programming in C++, using Victors, and 4 CIMs.

When I am driving both sides straight forward, I can give them a value of, for example, .2 and .2 and they respond appropriately. However, when I work on the turn, and attempt to give them values of, say, .3 and -.2, a motor being given a small value such as -.2 will simply do nothing. [The other motor will happily do what it is supposed to.] I didn't have time to do extensive testing but it looks like .3 is right around the cutoff: anything less than .3 will only be correctly implemented if BOTH sides [all four motors] are given that same value.

Does anybody have any ideas as to why this is happening? At this point I'm just working around it by turning with higher values such as .4 and -.3 but I'd LOVE to go slower...

Originally Posted by Matt Krass (Post 1037102)

Well, I just confirmed with IFIs site that those values are acceptably high enough to instruct the Victor to do something. (Minimum throttle is 3%) To confirm I would watch the Victors during these tests and see if the LED properly indicates what you are expecting. I wouldn't be surprised if the low power enough was simply encountering heavy drive train resistance and stalling the motor. The reason it probably works with both sides is because straight driving tends to put less physical strain on the drive system.

Matt

Originally Posted by Bethie42 (Post 1037104)

Thank you! I am pretty sure I did watch the LEDs at some point, but I have unfortunately forgotten whatever was observed. [That makes me suspect that they weren't indicating any stalling, but I could be wrong.]

I will check this at our regional [Week 4...so long to wait..ahh!] The strain you mentioned....is this coming just from putting a heavy load on the motor? Or simply from running just one side? We tried autonomous mode on blocks many times, and still got the same problem.

Originally Posted by Bethie42 (Post 1037099)

Here's another nervous programmer :D

I was writing autonomous mode at 9 PM on robot ship day. And shrieking when the line-following worked. And then rewriting autonomous almost completely so that we'd score as soon as we reach the tape-line T, not just overshoot it and ram the driver station as happened at our Week 0 event. And then we had to bag the robot. So autonomous never got fully tested.

Besides programming an autonomous mode that is going to have to be extensively tested and probably reworked, I am in charge of scouting, Chairman's, and am also team captain [I'm the only non-rookie student on the team]. I love my job but having code to write, hardware issues to keep an eye on, troops to marshal [ ;)], feisty limit switches to debug, matches to scout, judges to interview, and new students who are enthused but have no idea what they're doing who need to be briefed about EVERYTHING before the event.....I'm panicking just a little.

I suggest you make a list. [And probably another list, and another...] I've got loads more stuff to plan than you do [hopefully], but I find making a list of things that could go wrong and need to be fixed, things that have to be done as soon as you get to the event, things to check as the event goes on, etc is a good way to both calm your mind before the event, and be a lot more efficient during the fracas.
Also, there is no reason to be nervous about an FRC event unless it's your last year...like it is mine...enjoy it while you can. Good luck!

Lineskier, that is good to know about the .1 or .2 motor value/battery issue. I have a related question which should probably go in the programming forum but I'm going to stick it in here:
Our autonomous mode [the only place we feed a value directly to the Victors, as opposed to taking the value from joysticks] involves tank drive, going straight forward and turning [to correct if we've left the tape line]. I'm programming in C++, using Victors, and 4 CIMs.

When I am driving both sides straight forward, I can give them a value of, for example, .2 and .2 and they respond appropriately. However, when I work on the turn, and attempt to give them values of, say, .3 and -.2, a motor being given a small value such as -.2 will simply do nothing. [The other motor will happily do what it is supposed to.] I didn't have time to do extensive testing but it looks like .3 is right around the cutoff: anything less than .3 will only be correctly implemented if BOTH sides [all four motors] are given that same value.

Does anybody have any ideas as to why this is happening? At this point I'm just working around it by turning with higher values such as .4 and -.3 but I'd LOVE to go slower...

Originally Posted by Hjelstrom (Post 1037105)

Are you working with a high traction drive train like a 6wd with traction wheels in the corners? They just really really want to go straight. You have to give a bigger difference to the two sides to get them to turn.

Originally Posted by Bethie42 (Post 1037110)

Yes, I am giving one side a negative value [driving it backwards]. We're using 2-wheel drive actually, with the driven wheels in the front and two free-rolling wheels in the back.
And the problem isn't that the robot isn't turning, it's that one of the motor-sides just isn't engaging at all, even on blocks.

I discovered at the last moment that in order to turn the robot, as you said there has to be a big difference....hence, driving one side backwards. A fair bit of frustration would have been eliminated had I just driven the robot myself a little bit more to see how it actually works....yay for programmers integrating with the hardware team :)

Originally Posted by Matt Krass (Post 1037108)

The LEDs on the Victors simply indicate what the Victor is being commanded to do, they provide no feedback regarding stall / overcurrent.

If this was happening on blocks, it sounds like drive train binding to me. I'm not a mechanical guy, but I believe if the robot is actually moving forward, it may alleviate some tension in the drivetrain, but thats more hunch than fact. Is it consistently happening to only one side or both?

Matt

Originally Posted by Bethie42 (Post 1037110)

Yes, I am giving one side a negative value [driving it backwards]. We're using 2-wheel drive actually, with the driven wheels in the front and two free-rolling wheels in the back.
And the problem isn't that the robot isn't turning, it's that one of the motor-sides just isn't engaging at all, even on blocks.

I discovered at the last moment that in order to turn the robot, as you said there has to be a big difference....hence, driving one side backwards. A fair bit of frustration would have been eliminated had I just driven the robot myself a little bit more to see how it actually works....yay for programmers integrating with the hardware team :)

Originally Posted by lineskier (Post 1037109)

If you can get your hands on a vex ultrasonic its more reliable than the T, crazy easy to use and good to an inch or 2.
Regarding turning. Its very difficult for the robot to turn. I'm guessing your robot is geared similar to ours, and it just can't overcome the turn at low speeds. .3 sounds about right for the turn. This is actually a physical limit, because the force to turn is greater that the force to go forward. This is why I plan on working with a transmission next year. So I can have the force at the low speeds, but the speed at high.

However for this year, and your line tracker, try combining the correction and drive forward code. This will make it easier on your drive. ie, if your moving forward its easier to turn. one way to do this is to put a min Y in autonomous. so basically you are always going forward at least a bit. ( a .1 or .2 should be enough, but you'll have to play with that)

I had an interview thursday, so I missed out on the first day of comp, so I totally understand your stress. Again it sounds like the design is less conducive to a good autonomous, so maybe put less emphasis on it at first (you won't need it til saturday). Again you will get your autonomous working perfectly, the battery will change, and break everything. I'm not saying don't go for it, I'm just saying if it comes down to autonomous or minibot, go with minibot. ( I didn't and paid for it.) Also if your robot drives fairly straight, get an ultrasonic overnighted to you. You should be able to do a cap just using that.

also try talking to the mechanical team. They may be able to gear down the drive fairly quickly, which would make a huge difference for both you and the drive team. Our motors were overheating after 1 min, but then again we only used 2 cims. and if you can pick up off the floor, drive speed isn't that much of an advantage where as control is.

Originally Posted by lineskier (Post 1037118)

We have the same exact drive set up and had all sorts of problems. Beg them to gear it down.

also if you have the weight, ask them to chain the back 2 wheels. This should help too.

you don't on motor running cause the motors have a natural bias. Luckily friction of the playing field tends to correct this.

Originally Posted by Hjelstrom (Post 1037124)

Maybe one side takes more torque before it starts turning (e.g. binding as mentioned above). If the robot is off and on blocks, is it harder to spin the wheel on one side than the other? If not, maybe the victors are not calibrated the same. Its pretty easy to calibrate them so it wouldn't hurt to try.

Originally Posted by Bethie42 (Post 1037131)

We've tested that, the wheels turn about the same on both sides. I'm not sure that this is the problem, but how do you calibrate Vics?

Originally Posted by Matt Krass (Post 1037102)

Well, I just confirmed with IFIs site that those values are acceptably high enough to instruct the Victor to do something. (Minimum throttle is 3%) To confirm I would watch the Victors during these tests and see if the LED properly indicates what you are expecting. I wouldn't be surprised if the low power enough was simply encountering heavy drive train resistance and stalling the motor. The reason it probably works with both sides is because straight driving tends to put less physical strain on the drive system.

Matt

Originally Posted by Joe Ross (Post 1037149)

There's a couple of things that complicate this.

By default, robot drive squares the input values. If you give it 0.2, robot drive outputs 0.04, which would be barely enough to turn on a victor.

Originally Posted by Bethie42 (Post 1037131)

We don't have any weight to spare, unfortunately :( [one of our projects today is getting our 30-lbs withholding allowance under 30 lbs...]

Ahh ultrasonic sensors! The one sensor we didn't think to use...I think I will stick with the line-following though, I'm not keen on testing a new sensor at regionals. Although it sounds like it would be a great addition, we could steer to the scoring grid using my beloved light sensors, then stop at the right spot using the ultrasonic....at one point we considered using encoders as a safety net to avoid driving straight into the driver station, but scrapped that idea because I eventually realized that a LOT more encoder-ticks will go by if you are line-following and correcting than if you are just pushing the robot straight, heh.

I'm not quite understanding what you're saying about putting a min Y in auto...the only time the code stops the motors is if we've gone entirely off the line, otherwise it just switches one of the motors to run backwards and the other keeps going forward. [Not that that was particularly easy to understand on my part, heh.]

Gearing: I think our gear ratio is okay [actually, I am trusting our lead mentor on this]. We geared it to not be terribly fast, and the drivers seem happy with it, AND with all the other stuff that will break/need to be optimized, I'd rather not be swapping out gears...
However, I will talk to our mentor about this today, find out what our current gear ratio is and check that it's what we want. Thank you for the tip!

Thanks!