Another observation from Sat. As we reduced the range our RPM fell on the "spinny thing of dooooom!" and would actually jam up. This is another place where we need to look to adding the PID block to keep the RPM constant. We may need to play with it as the PID block will need to feed more power as we launch balls to keep the rpm up and not jam. Another task for us to get working tonight is the encoder feedback from the "spinny thing of dooooom!".

Well we ran the controls in manual mode with manual speed control. Suggestions were made about being able to revers the elevator and the ground hog. Software will need to look at some options to do this with the controls on hand.

James worked with Dean to adapt a PS2 controller to work with the drivers station. This still need to be tested to make sure all the buttons function. The axis controls need to be fine tuned as well.

Final dashboard designs need to be done so we can have mechanical and electrical look at constructing it for us as software team fine tunes the robot.

We also have an issue with the new camera code bogging down the control system. We need to do some debugging tonight (Monday) and see what may be causing it.

Lots of software work to do still!

We made really good progress last night. We connected the turret and ran it on circles. Runs smoothly. We did have a gear slip on the encoder shaft so there is work to add a set screw. Looking to possibly test tonight with the encoder in place.

Manual turret control is done, needs to be tested fully. Once the camera is added we will work on tracking the targets and turning the turret.

Elevator motor control is in place and the groundhog motor reference is added. Need to set the control.

Look to add the automated tracking system and determine how we want autonomous to function completely.

Looking forward to making more progress tonight.

Just sharing from the experiences digging through the blog code. Before looking through the code I had never looked at PHP before. What I wanted to express is learning multiple languages is a way to gain skills to be able to quickly look at a new language and be able to understand what it is doing, even if you never have programmed that language before. Almost all languages share common structures, styles of design, and operations.

So, moral of the story, learn as many programming languages as you can in your career as a software developer. Read, research and try languages on your own. With that background it will increase your skills and give you abilities to quickly learn other languages.

For the ball harvester I think we will need to slow the intake roller down to a speed just slightly faster than our robots max speed. If it spins to fast as we come up to a moon rock it will kick it out because of the slick floor rather than pulling it in. Of course this is just a theory and needs to be tested. So if we want to spin the intake roller to match the robots max speed what RPM would we need? Below is an example of the math that I used to calculate the RPM. Some of you math wizards should make sure this is correct.

Formula for circumference is: Circumference=3.14*diameter
The formula for inches per second based on RPS (revolutions per second) and the circumference of the wheel is: in/s = RPS/circumference
RPM=RPS*60 In order to get RPM we need to multiply RPS by 60
Diameter = 5 Lets say our intake wheel/brush has a diameter of 5 inches
5 * 3.14 = 15.7in
Let’s say our robot can travel a max speed of 12 feet per second. Now let’s convert that to inches per second: Inches per second = 12 feet per second * 12 inches per foot = 12 * 12 = 144in/s
Now calculate the RPS: 144/15.7 = 9.17 RPS multiply by 60 for RPM and we get 550 RPM

The software team started into the development of the final version of the program. Switched to the advanced template after the labview software updates were applied so we can flash (deploy) the program to the cRIO for use on power up.

We also went through and talked about software requirements and the process of using UML use cases aka user stories on how we expect the robot to function. We went through what an actor is and how the actor interacts with the use case.

We are targeting to complete all the manual interaction by Saturday, then work on the automated parts (autonomous and automatic camera targeting).

Dashboard design is almost complete for the physical part, the software part still needs to be developed.

made a sub vi named camera stalking.
This routine sets a value to the motors based on the position of the camera to turn towards a target. It then goes towards the target until it is a certain distance away. (as of the moment too close to be read by the camera).

problems we had
connecting to the autonomous.vi terminals
executing our own sub program camera stalking. It was labled as non-executable.

today we went over chasis and camera mounting options .... we researched on the teams and color cordnation. we set up plans to test distance formulas for the camera. James worded on the gyro chips and acceleramitor.

http://www.ni.com/pdf/manuals/372192b.pdf

Take a look and let's determine if we can use it.

Found it on Chief Delphi tonight.

Ok, this is for everyone. I know there are folks on the team that are thinking about driving this beast. With that we need to determine what the best style of control will be.

We have used the xbox controllers in the past with great success. It gives the drivers a degree of movement flexibility. We can use the joysticks from the kit of parts, but we need a drivers station set up to handle them.

If we decide to use something other than the joysticks from the kit of parts, then we need ideas and fast of what we are going to use, especially if we need to order them.

Electrical, can we get a sample of the encoder output, or a test bed one set up so we can get a test signal to code to?

What about other sensors? Software, we need to have a final list on Thursday if we can. With some of the major things of the camera behind us now, we need to move forward and finalize the last of the software design.

I think the goal is to by the end of Sat have a working drive model with proper controls to the driver. So be ready to work hard! I see two teams on Sat, one working with the encoder input, and one working the drive system design.