-
Robot game rules
-
FLLTutorial resources
-
Points Calculators
-
Last Year
- Wordynerd48
- First Lego League Tutorials
- EV3 Lessons
- highlandersfrc - robot design
- MOC - Super Small Box Robot by FLL Team Moscow
-
Simulator Tutorial Videos (work in progress)
- Driving straight using a gyro and PID algorithm
- Lego's Documentation - html
- PyBrick's MicroPython Documentation - pdf
- Lego EV3 Programming Language research
5. Hardware
More practicing; robot performs less accurately with time - need to remember to clean wheels, caster and challenge mat. Added bench backrest lift mission.
Robot worked very well for first 45 min, then had problems; thought it might be the gyro, but after rebooting a couple of times, tried cleaning wheels, mat and caster wheel, and this fixed things.
Robot not reliably working, not clear why. Maybe gyro, maybe battery.
Recreated Boccia bucket attachement; Tried a few complete runs, now having problems with forklift again... reliability issues have been plaguing us from the start.
Gyro navigation much better with forklift now being centered; forklift move to centre-front of robot initiated a change gear design that improved the workings of the forklift; forklift now has speed and strength to lift the baskball easily; working through changes in code to get boccia/basketball/bench missions to work.
Moved forklift to front centre of robot, so it is more balanced (given that it is a trike robot with ball caster in front, having forklift on right had side caused many navigation problems) and no longer using worm gear - too slow and not as strong as one would expect - used Yoshishito Isogawa's Lego Minstorms EV3 Idea book to come up with better small-gear-to-small-gear change-of-direction solution; reinforced and strengthened forklift so that it is more reliable; also reinforced the box around the robot frame to improve robot navigation reliability - wobbly box around main robot frame may have caused issues with trying to drive in straight line, since wheel axles are attached to box walls.
WIP - moving forklift to centre of robot
Finally figured out that the forklift attachment, was sometimes (not always), causing the robot to drift left - the opposite direction that the attachement was placed on the robot. Our robot is a trike (3 wheel) robot with the caster wheel in the (centre) front. Our forklist attachment was on the right-hand side. This was causing the robot to sometimes drift left. Options to fix: move forklift to centre; add counter-weight to robot on opposite side of forklift; add a second caster wheel; add a beam across the front of the robot so that caster is no longer being used. Also addressed problem where robot would jiggle at start - lego motors have a bit of play (2-3mm of free motion when not engaged). This may be causing random changes in direction when robot first started. Solutions: make sure both motors/wheels are rolled forward, then placed on starting position - so they have equal play; implement ramping up code so that robot does not try to go to full speed immediately.
robot seems to lean left when going straight - tested motors to make sure that they are both running at same speed (put lines on motor and ran for 5 secs and see if they remain parallel).
Trying to figure out why robot seems to jiggle as it makes its way to the basketball mission, sometimes missing the mission altogether... Tried to ramp-up to target speed, also tried tweeks to the robot movement code. It does not seem to be a problem with the gyro_straight parameters or the starting angle of the robot (though a jig make sure that this is not the problem...) Best solution seems to be to adjust the PROPORTIONAL_GAIN field in the gyro_straight function from 1.1 to 1,2 - need to experiment more with this.
Robot not working the same as on Thursday - off just enough to cause problems with missions. Possible cause: Batteries from different manufacturers - we use rechargeable batteries from two different manufacturers: Duracell and Eveready. Everything worked fine on Thursday with the Duracells, after making minor tweaks to the programming. Saturday a.m. switched to the Evereadys (since they were fully charged), and since they have sightly higher baseline voltage, it seemed like we were consistently overshooting our missions. Going forward we are going to stick with same batteries, and recharge after every session. No going back and forth. Would like to order an EV3 battery pack, but the charger is no longer in stock. In addition, because we were able to record as many sessions as we wanted within a 6 hour window, we cycled through many mission attempts. The problem is that the removal of our forklift and bucket attachments was not always clean and this caused problems with reassembly and hurt our ability to reliably perfom the basketball/bocci/bench and bocci bucket missions. Feedback from judge: our M01 Innovation Project did not count because we have it on top of our health units (so they can be touching the logo) because it is not also touching logo.
Ran through the process of recording our mission runs. Worked on the intro and running the actual missions and review of results. We managed to get 250 points on one run. Question asked to FLL Support re putting robot on its side for M00 Inspection... they said: You can actually position your equipment any way you would like and even use your hands to hold stuff in place. As long as this fits in that volume (however you manage it), it would be allowed!
Potential to make 275 if everythig works as planned (Inspection Area, M01-Innovation Project & M14-Health Units, M02-Step Counter, M04-Bench, M06-Pullup bar, M07-Robot Dance, M08-Boccia, M14-Health Units, M15-Precision.) Boccia scoring update - can score the 25 points for sending either a red or a blue cube from the share model, but not both.
Simplified program so that it now uses fewer turns - less chance of misalignment. Not perfect, but better than before
Still not working correctly - no clear where the problem is. Trying new program from scratch with fewer turns, and making sure any gyro_straight commands are for long enough distances for gyro to make corrections (e.g. 20mm distance is too short and gyro cannot make correction fast enough). Finally figured out that hand tightening all the pieces on the forklift before every run, along with tightening the box portion of the robot is required for repeatable runs.
Finished rebuild of forklist attachment; fixed gyro_straight() bug so that robot can now use gyro when going backwards in straight line. Robot more accurate on turns and travelling straight.
Trying to get old forklift attachment to work since it seems more stable; also worked on trying to stabilize current fork lift attachment - will pick whichever one works best. Started on a new gyro_straight function - our gyro was reversed, took a while to figure out that we need to set our gyro with reverse direction (to fix angle error measurements were the opposite of what one would expect).
The basketball hoop was getting caught at junction between blue vertical beam and black vertical beam. There were many, many varied attempts/modifications to correct the robot fork lift attachment, when it was the mission design/construction that was the problem. Good lesson learned: make sure all mission pieces fit snuggly after every attempt at trying the mission.
incorporated Challenge set wheels to even out robot height (old wheels were too tall causing the robot to lean forward); fixed cabling issues: cables were rubbing on wheels causing random direction changes, this coupled with some loose fittings made for a very erratic robot - seemed like we went backward in terms of robot development. But once these issues were resolved, robot ran cleanly and kids started working on missions once again.
Not enough to just change axle sizes, need to reprogram. Drivebase class makes it seem like you only need to change axle sizes it you build new robot without changing you programs, not the case for us. Change of direction of motors and changing settings speed parameters to negative numbers should be the only required change... maybe we are missing something. Confirmed with First re:strategy of attaching the health units to our innovation project - no equipment rule only applies to pull-up bar, so our strategy OK as long as health unit 'touching' RePLAY logo - i.e. on bottom of our innovation project
M00 Inspection Bonus (20); M02_step_counter.py (15); M04_M08_bench_boccia.py: M08 Bocci (15); Bench (10); M01_M14_M06_M07.py: M01 Innovation (20), M14 Healt Units (3 x 5=15), M06 under pull up bar (15), M07 Robot Dance (20); M15 Precision (60). For a total 190 points in 2 min.
Confirmed with First that for mission M01 Innovation Project, we can attach the 3 'home' health units to our
innovation project and have the robot move this as one object to the RePLAY logo, so this will also count for
3 M14 Health Unit points.
Their response: "Great idea, and since the Units do not require that they not touch equipment and since the
innovation project does not require it to be standalone, this combination would work and earn points for both
missions at the same time."
team discovered that this approach not the best because if you change the speed of the robot, need to also change the running time - good learning experience. Reverted to using odometry in robot.straight() for distance calculations. Did run through of M02 mission and combined M01_M14_M06_M07 missions.