View unanswered posts | View active topics It is currently Mon Oct 26, 2020 7:03 am

Reply to topic  [ 2 posts ] 
Inconsistency with programing 
Author Message

Joined: Tue Feb 03, 2015 2:30 pm
Posts: 1
Post 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.

Thank you.

origonall skill.c [13.62 KiB]
Downloaded 360 times
skills challenge blue states.c [13.62 KiB]
Downloaded 393 times
Tue Feb 03, 2015 2:57 pm
Site Admin
Site Admin

Joined: Thu May 24, 2012 12:15 pm
Posts: 722
Post 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. Motor speeds of 70 may be too high for accurate movements and turns
  2. Sonar controlled movement may vary if you get an odd reading or interference
  3. All of the arm control commands are using time-based movements

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.

Check out our Blog! And our Facebook page!
Need help? Take a look at our updated help documentation and the ROBOTC Forums.

Wed Feb 04, 2015 1:03 pm
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.