Reviewed the results of timing and conducted more tests.
Also we geared up the faster new gun – should be ready to go this week.
In reviewing the timing, the majority of time is lost on missing the first shot. Mechanical movement time makes up the vast majority of time consumption, especially corrections, followed by shot time itself.
In reviewing time consumption is was clear that the number of movements per target was very high due to incorrect targeting initially.
The new gun targeting moves faster, but the mechanical moves still take up most of the time (and always will). The key is to properly match the pointer to the blob correctly the first time, so no corrections are necessary. Then improvements in mechanical speed will have a significant impact on the overall times.
Tuesday, May 5, 2009
Monday, April 20, 2009
TAKING IT UP A NOTCH!
Only 6 weeks left until we go to Robogames. TAKING IT UP A NOTCH!
We've initiated time trials!
Early time trials with all 14 targets are all over the map due to manual gun reloading. It's rediculous! The thing runs out of bullets. This is very similar to our experience at Defcon.
logfile: start_time end_time difference(seconds)
playeratat-20090419143614.log: 413 626 213
playeratat-20090419145133.log: 114 222 108
playeratat-20090419152502.log: 278 647 369
playeratat-20090419153853.log: 518 693 175
playeratat-20090419162203.log: 87 256 169
playeratat-20090419162735.log: 38 136 98
playeratat-20090419163742.log: 226 374 148
Mean - 182.9 - approx 13.06 seconds per target
To get a better picture, we reduced the number of targets to control for the gun capacity. We did several time trials with 3 targets and established that the primary limiting factor is the gun and its misfires.
playeratat-20090419164925.log: 73 88 15
playeratat-20090419165235.log: 18 30 12
playeratat-20090419165809.log: 26 36 10
Mean - 12.3 - approx 4.1 seconds per target
The new gun won't be useable with the existing hardware without downtime on software, so we're holding off using the new gun until the new hardware is complete in order to keep software development going. Unfortunately that means that our time trials are essentially invalid until then.
To bridge this, Daniel will be doubling down on his efforts to finalize the hardware this week.
This week:
The new DC Driver interface tested and integrated with PLAYER successfully.
We attempted some pixel mapping methods (such as opencv) but found that hard alignment of camera to target screen was easier an more effective.
We also attempted varying light conditions using the 1500 watt halogen but it intoduced a bunch of shadow that was inconsistent with the test environment anyways. We won't be using that anymore.
We've initiated time trials!
Early time trials with all 14 targets are all over the map due to manual gun reloading. It's rediculous! The thing runs out of bullets. This is very similar to our experience at Defcon.
logfile: start_time end_time difference(seconds)
playeratat-20090419143614.log: 413 626 213
playeratat-20090419145133.log: 114 222 108
playeratat-20090419152502.log: 278 647 369
playeratat-20090419153853.log: 518 693 175
playeratat-20090419162203.log: 87 256 169
playeratat-20090419162735.log: 38 136 98
playeratat-20090419163742.log: 226 374 148
Mean - 182.9 - approx 13.06 seconds per target
To get a better picture, we reduced the number of targets to control for the gun capacity. We did several time trials with 3 targets and established that the primary limiting factor is the gun and its misfires.
playeratat-20090419164925.log: 73 88 15
playeratat-20090419165235.log: 18 30 12
playeratat-20090419165809.log: 26 36 10
Mean - 12.3 - approx 4.1 seconds per target
The new gun won't be useable with the existing hardware without downtime on software, so we're holding off using the new gun until the new hardware is complete in order to keep software development going. Unfortunately that means that our time trials are essentially invalid until then.
To bridge this, Daniel will be doubling down on his efforts to finalize the hardware this week.
This week:
The new DC Driver interface tested and integrated with PLAYER successfully.
We attempted some pixel mapping methods (such as opencv) but found that hard alignment of camera to target screen was easier an more effective.
We also attempted varying light conditions using the 1500 watt halogen but it intoduced a bunch of shadow that was inconsistent with the test environment anyways. We won't be using that anymore.
Sunday, March 22, 2009
TITI VOLUNTEERS FOR TARGET PRACTICE
Titi - Your sacrifice for science is appreciated.
Thanks Titi!
Software Day!
Today:
Implemented and debugged load/save config
Integrated auto-calibrate with load/save config
Implemented basic logging of target counts and times
Built power board for motor controller
Began testing new motor controller player interface
Morgan also helped here
Thanks Titi!
Software Day!
Today:
Implemented and debugged load/save config
Integrated auto-calibrate with load/save config
Implemented basic logging of target counts and times
Built power board for motor controller
Began testing new motor controller player interface
Morgan also helped here
Monday, March 9, 2009
ROBOT GUN TURRET 3/8/09
PREPARING FOR
ROBOGAMES 6/12 - 6/14 in San Francisco
Today:
Strengthened rotation with geared down motors
Reduced play with MORE METAL
Refined blobfinder capabilities for calibration
ROBOGAMES 6/12 - 6/14 in San Francisco
Today:
Strengthened rotation with geared down motors
Reduced play with MORE METAL
Refined blobfinder capabilities for calibration
Sunday, February 8, 2009
ROBOT DAY 2/8/09
Today our focus was to develop the new, faster turret and update the automatic calibration in the software.
We added player capability to allow real-time modification of the blobfinder specs (screenshot below).
We also wrote the specs on calibration and settings saving, autosaving, loading, and logging. This will be implemented in the coming days.
Daniel developed boards for the infrared limit switches (the limit switches are shown below). These will be incorporated into the motor controllers (still on order) and the existing Arduino microcontrollers.
We added player capability to allow real-time modification of the blobfinder specs (screenshot below).
We also wrote the specs on calibration and settings saving, autosaving, loading, and logging. This will be implemented in the coming days.
Daniel developed boards for the infrared limit switches (the limit switches are shown below). These will be incorporated into the motor controllers (still on order) and the existing Arduino microcontrollers.
Monday, January 26, 2009
Robot day 1/25/09 - new turret development
links to our projects:
http://www.sourceforge.net/projects/aion/
http://www.sourceforge.net/projects/firmataplus/
http://www.dataczar.com/
Today we spent some time building the new turret and worked on auto-calibration for our playeratat software.
We're creating the new turret using DC motors with optical encoders to increase power and prevent the step-skipping we've been getting with the stepper motors on the current turret implementation. The step-skipping has forced us to slow the motors down considerably from what they should be. By switching to DC we should be able to dump as much power as we want into the motors without worrying about loss of accuracy.
Since the previous competition we increased the size of the stepper motors on the original turret and we added a color camera to the base to enable auto-calibration (not yet implemented). The increased motor size allowed us to increase the speed because the skipping "stall" threshold was reduced, however we are still limiting the speed considerably to prevent skipping. Skipping must be prevented because in the absense of sensors to indicate the turret position, it is impossible to know the position of the turret if a skip occurs.
The new implementation turret includes optical encoders to feedback motor position information. DC optical motor controllers are on order for the new turret. We have Player (http://playerstage.sourceforge.net/) drivers integrated for the current stepper-motor implementation. When the new motor drivers are received we'll probably need to create custom Player drivers for them as well.
http://www.sourceforge.net/projects/aion/
http://www.sourceforge.net/projects/firmataplus/
http://www.dataczar.com/
Today we spent some time building the new turret and worked on auto-calibration for our playeratat software.
We're creating the new turret using DC motors with optical encoders to increase power and prevent the step-skipping we've been getting with the stepper motors on the current turret implementation. The step-skipping has forced us to slow the motors down considerably from what they should be. By switching to DC we should be able to dump as much power as we want into the motors without worrying about loss of accuracy.
Since the previous competition we increased the size of the stepper motors on the original turret and we added a color camera to the base to enable auto-calibration (not yet implemented). The increased motor size allowed us to increase the speed because the skipping "stall" threshold was reduced, however we are still limiting the speed considerably to prevent skipping. Skipping must be prevented because in the absense of sensors to indicate the turret position, it is impossible to know the position of the turret if a skip occurs.
The new implementation turret includes optical encoders to feedback motor position information. DC optical motor controllers are on order for the new turret. We have Player (http://playerstage.sourceforge.net/) drivers integrated for the current stepper-motor implementation. When the new motor drivers are received we'll probably need to create custom Player drivers for them as well.
Thursday, January 22, 2009
Subscribe to:
Posts (Atom)