|Inconsistency with programing
|Page 1 of 1|
|Author:||pmd5 [ Tue Feb 03, 2015 2:57 pm ]|
|Post subject:||Inconsistency with programing|
I’m looking for some support with the Autonomous. We have a consistent problem with programing when working with autonomous; the autonomous will hit 5 for 5 and then we stop. Every time we reload it the next day and each time we have to reprogram everything we did from the day before. I have attached the 2 files we use for Autonomous.
The robot itself is a scissor lift robot with a claw in the front and a cube intake in the back. We are using a gyroscope and a ultrasonic sensor/ range finder.
Please note that we have tried using shafting coders as well.
|Author:||JohnWatson [ Wed Feb 04, 2015 1:03 pm ]|
|Post subject:||Re: Inconsistency with programing|
At which point in the program does the autonomous routine start to fail? There are several potential issues that you could be running into, including:
1) When you run the motors at a high speed, the robot tends to carry quite a bit of momentum. When you tell the robot to suddenly go from a fast movement (speed 70) to a complete stop (0), it's the equivalent of telling an automobile driver to go 50 mph, then slam on the brakes as soon as the front bumper reaches a stop sign; the robot will not stop on a dime and instead will 'drift' a bit. The amount of drift is affected by the drivetrain configuration, type of wheel being used, type of surface being driven on (and cleanliness of said surface), and most importantly speed. Try reducing the speed of the encoder-based movement down to a slower value to help reduce this drift.
2) Sonar sensors work by 'pinging' sound waves off of objects, waiting for a sound wave to bounce back, then recording how long it takes for the sound wave to return to the sensor. Normally this will produce very reliable readings; however, if the sound wave is deflected away from the sensor or absorbed by the object, the reading can become false. This is especially true if the object being detected has sharp angles, is a 'soft' object such as carpeting or clothing, if the object is round, or if it is small. Unfortunately, the skyrise sections and cubes contain many of these elements (small, rounded objects) and while you may be able to detect them on one run, they may not be detected on another. There is also the chance that additional sonar sensors on the field/in the proximity of the field can be causing interference with your robot's sonar sensor readings.
3) The problem with time based movement is that the motor commands are directly based off of the amount of battery life left. As the robot moves, it is constantly draining the battery life, which will adversely affect the movement of the robot's motor power levels. While this may not seem noticeable at first, even a small amount of deviation of values between one movement and the next can quickly add up; this is known as 'accumulated error'. To resolve this, I recommend using encoders on the motors, if possible, to ensure the motors are moving as accurately as possible (no matter what the motor's power levels are at).
With these particular programs, you have quite a bit going on (5 skyrise sections built); as the program continues on, any small errors that aren't corrected can accumulate and cause problems later on in the program. Besides the suggestions listed above, I suggest looking at adding in some error correction through the use of multiple sensors. For instance, instead of using just the sonar sensor for forward movement, you may want to look at both the sonar sensor and encoder values for forward movement. The more complex the behaviors of the robot, the more you will need to ensure that the robot is making its movements as accurately and repeatably as possible.
|Page 1 of 1||All times are UTC - 5 hours [ DST ]|
|Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group