Hello, I was wondering how teams without sensors program. I am referring to giving the motor power, setting a wait statement to move the motor, and setting the motor power to zero. I know our “F” team kept the battery a constant level whenever programming, but I found that very tedious. With the Cortex microprocessor and RobotC for Cortex & PIC, I remember a function that checks the current battery level (correct me if I’m wrong). If this does exist, and one is wiling to spend time testing out the program several times on different battery levels, the programmer could use switch cases or if statements to change the program according level of the battery. I am not sure if this function exists on EasyC V4. This is just a suggestion for teams without sensors (if the function I mentioned really does exist). For teams using dead reckoning to program, I would like to ask, “How do you ensure that you get your program right every time?”
Short answer: You don’t.
When I have to work with those conditions, I’d make several teleop runs of the routine, average the time it took to complete it, and use that as the value. Only a few simple operations could really be done reliably.
Timed autonomous runs are pretty much always going to be unreliable, especially a multiple step routine. If you absolutely can’t use encoders or light sensors or anything, limit switches and bumper switches can still be helpful! Need to score on a high goal? Raise your arm until you trip a limit switch, lower it a timed amount, and dump. Going for a lower goal? Depending on your robot’s configuration (if you have a little cutout for the goal to “slip” in) you could use two limit switches to detect the goal in possession.
Some lack of autonomous prowess can be compensated for in mechanical design. If you don’t have the sensors needed to precisely place a needle grabber inside a stack of tubes, maybe you could build a wide, sweeping pinch claw instead. You could use a traction - omni drivetrain to move your robot’s center of rotation to wherever is convenient as well.
Remember, the field is SURROUNDING your robot with information - walls, tape, anything. Not having encoders might suck, but you can still make something happen.
This is a sideways reply to the OP.
I have often wished for volatage monitoring software function or a device that would be legal in VRC and that would feed a voltage measurement into an analog input port on the microprocessors.
However, there isn’t one, and it isn’t obvious that you could hack a legal one (for VRC) together using the legal parts.
But, I can think of one idea that might work. I would love to see results (nice graphs, etc.) from students/teams who try this or their own methods.
- Turn a motor attached to a shaft encoder and nothing else (or perhaps put a small load (a fan?) on it). Use the encoder’s counts per second to measure the motor’s RPMs, and use the RPM value to estimate the battery voltage. Sadly, this would use up a motor port.
Alternatively you could add load to a motor until it stalls (perhaps have it pull on a bundle of latex tubing) (measure the rotation with a Vex Potentiometer) to see if the stall torque is a good/better indicator of how the battery performs under a load. However, stalling a motor is generally the wrong thing to do.
To address the OP’s original question - Once you know battery voltage’s effects on your robot, and once you know battery voltage during an actual match, I think that automatically adjusting autonomous dead-reckoning code (code that uses timers instead of measuring distance traveled or angles) is exactly a good thing to do.
Blake
PS: If the Cortex reports Battery voltage, then obviously my thoughts about how indirectly measure the battery voltage are only important to the teams using the PICs (and who have a spare motor port available).
I completely forgot about touch sensors until now.
I think I’ll mention this to our F team…
There are two functions in RobotC that checks the battery voltage. One is batteryAvg, which checks the average battery level in millivolts. The other is batteryLevel, which checks the last sampled battery in millivolts.
I am not sure if these require an sensor to be detected, however I tried making a sample program, and it compiled just right. Didn’t test it though-
I think it is built into the microprocessor, however I am not so sure on the hardware.
-I read on, and you do have a point. The new timers are more accurate, and one can do a similar sampling method. However, the functions above only apply to the cortex.
you can also use the walls as a perpendicular line-up
many teams did this in elevation and especially in clean sweep
didnt wee many in round up, but then again, not many of the robots HAD an autonomous…
another great way is instead of making the motors 100% forward, make it 50% or even 25% so the battery voltages will make less of a difference
the teams who dead reckon generally dont have much to do
knock over a stack
close the claw
ram into another robot
these methods do not need much precision
My middle school team was able to consistently score the preloaded ring on the wall goal and a stack of rings on a movable goal in autonomous. The only sensor they use is a limit switch in the concave part of the robot to know that they had hit the movable goal, everything else is dead reckoning. They changed batteries every other match and did not have any problems from low batteries. The only times they missed were the one time there claw got stuck on the wall goal or when another robot moved the movable goal or rammed them.
Before our next competition in March they are planning on adding some sensors that will let them cut a few seconds off their time to score on two goals and allow them to at least go grab another stack of rings.
Jay
If you have a limit switch, it is possible to make an encoder. It won’t be extremely precise, but it will get the job done. Take a gear, and screw small standoffs around the circumference at even intervals. Then put this gear on the shaft that drives your motor. Position a limit switch so that it clicks every time a standoff is pushed into it, and then is released when that standoff has passed. Of coarse, it’s easier to buy encoders or ultrasonics, but this will work if you’re desperate. Ask me if I haven’t been clear or you need the code.
I’ve done that for a LEGO competition bot last year, I think we were doing sumo’s. The clicker was a seperate wheel touching the ground, so the motor shaft was not connected to it. We had this cool brake system, and when the wheels were slipping (indicacted by the touch sensor not being clicked despite the motors being commanded to go forward) we slammed down the brakes, so they couldn’t push us. It works okay… kind of low resolution and sorta ghetto, but it worked.
I remember doing this in the McKinley VEXhibition. We didn’t have any sensors, and for most of the team, this was their second year. Sadly, EasyC, the VEXnet Upgrade, and the PIC microprocessor didn’t “click” well and kept on looping our autonomous.
I noticed on Youtube and in later competitions that people aligned themselves by ramming the movable goals first, and backing up a certain distance to ensure they scored.
Off topic: I noticed how teams were knocking down their opponent’s tubes. When you think about it, it is a bit of an advantage to other team.
At Pan Pacific, it was a vital strategy to place tubes under the ladder. When the stack is not knocked over, it makes it easier both teams to grab. Your opponent will have a harder time grabbing tubes and placing it under the ladder if the stack is knocked over.