So far, the first 3 weeks (programming wise) has been to implement all the sensors and test them. What should have taken a week took 3 weeks because of disagreements and arguments between programmers and other minor problems. I believe it was the lack of communication on my part that slowed down the process. So far, we do not have a working arm or code for the arm. The drive code remains almost unchanged since week one. It just feels slow overall this year. Last year went quicker because I was the only one programming and everything is in my head. My mentors had this lecture on graphing and verifying everything. Today, I spent about 2 hours getting data, filtering through the data (20,000 data points) then graphing the data to only find out that the encoders are not working correctly. It turns out I forgot to update the libraries and that there was a major bug in the last year’s library. Now I look like a arrogant, narrow minded tyrant. :rolleyes:
So far what we have:
Working drive
Minibot deployment system
Pretty much it…
What we are working on:
Arm
Minibot
Minibot and deployment system interaction
Communication between people
our drive doesn’t work, we cannot get communication, CAN has yet to be tested, all the motors are pulsing back and forth rather than spinning in one direction, and it still cannot turn. i think we will be OK, mainly because the Programmers have the actual robot now to work with, and they are hopefully pretty smart.
Not too terrible. Our team has never had this many programmers (7) either, and we use C++ too so it was an interesting challenging getting them all taught.
Unless build team is done and ready to test, you are fine. If not, you are causing huge problems for your team since they can not test stuff.
Programming wise I think my team is in a good spot. We got our CAN system working, and almost every sensor we plan on using to work except the camera. We still need to mess around with that.
I think we can manage to pull off programming fine if the robot is built completely before the last Saturday to give us time to test code.
I think I know what’s wrong with your motors, as we had a similar problem before. The motors seemed to be spinning randomly because we wired the input of the motor controllers to the motors and the output of the controllers to the power board. Check to see of your wires are switched around.
Well, now that you are asking, if you are not sure that you are on track, you should be driving and practicing by now. Ship is two weeks from today and if you ship a robot that you haven’t driven, it will be a surprise for your drivers at competition. Play with the robot before you ship. If you can’t drive, the best arm design in the world will do you no good.
Drivetrain code is tested, and debugged, and has about a solid week of improvement (and the robots aren’t actually driving yet). Constants will need to be tuned for both robots. Still more to improve, so I will have some work to do here.
Camera code has been tested and debugged, and has a solid Saturday of testing and debugging (a good 8 hours, stopping only to change batteries).
The autonomous driving and turning code has been debugged and tested. The routines will call these these two functions for almost all of their movement.
All of the drivetrain automation has been written, and 1/2 of it has been tested, but it needs more improvement to fix annoyances. This is mostly based on inputs which are not very robot-specific, so it should transfer nicely to the final robots.
The mechanism code has been written and not yet tested.
The claw code has been written. Some of the sensors have been tested independently, and shown to work.
I used a chassis which we built in the fall. It has a pair of stock Toughboxes and kit wheels, in the same wheel configuration that the final robot will (although it has Super Shifters). It has a pair of encoders, a gyro, and a camera. I developed all of my code on this robot. The only thing I couldn’t write and test was the shifting code, which is mostly logic so it is fairly easy to test in a simulator.
My point: You shouldn’t need tons of time to code on the actual robot. All of the code should be at least somewhat tested, either in simulation or on another robot. If you know the code works, and can fix bugs you find, changing the tuning constants to match another robot is very fast and easy.
Havent pulled electronics off of 2010 robot
Have yet to start any code
No design for electronics board
frame complete
arm half done
hand still to go
mini-bot just came out of the pieces box
Well let’s see, we got our robot driving, but we dont have the final frame on it yet, our arm is getting built atm and the hand is coming along. Our mini-bot can climb and come down, im not sure if they have programming for it yet, our final design for the platter has been put out, our 2010 and off season bot have been stripped, planning on using that for the platter. Supershifter are working, we are doing pretty good, some driver training has been done on how to approach the pole, how to enter the lane and positioning for the peg walls. So we have been doing good in a manner of speaking but man, going from meetings 3 days a week to 4 have been killing me. Also i have been doing more but still! Gah!
Sounds like my team a few days back. We’re way behind the schedule we laid out, especially after an unexpected snow week. It’s gonna be a struggle to get the bot together for a scrimmage the weekend before ship.
Frame done, chassis still needs chain to be reworked and components to be placed correctly.
Program not started.
Sensors not placed.
Our arm design was just scrapped and is being redone for another method.
Minibot is almost complete but completely untested.
Deployment is very iffy looking and not finished.
Soo… We’re ahead of last years schedule!
I’d recommend skipping the scrimmage if you’re that behind. You could have an extended build session in the time you’d be scrimmaging with a duct-tape robot (my own term for a robot that was thrown together in a rush).
We’re pretty far behind on programming…haven’t played with sensors at all, aside from the potentiometer on the arm, and it’s program. That mostly works. And the drive code works, but it needs a few tweaks. And pneumatics works. I think we can probably get the minibot deployment motor to turn, that’s something we have a good handle on how to program. We did find the camera yesterday and installed it last night, and someone was working on line following algorithms or something, although there’s no sensor on the robot.
So…we’re way behind, but we have a mostly working robot program. Maybe we’re not so far behind after all.
I think we did good this year, programmers haven’t wasted any time messing with sensors that we wouldn’t be able to implement anyways.
-Drive base finished and working.
-Teleop programming mostly worked out, sensors mostly coded.
-Autonomous not begun.
-Minibot prototype climbing quickly but not quite at ideal speed.
-Minibot deployment prototyping still underway.
-Arm/linkage/lifter/elevator/insert term here 60% done.
-Gripper prototyping complete, awaiting start of final build.
