Browse: Page 2
By Chris on December 9, 2010
Because we refactored the code to treat the robots as objects, it was a cinch to add in a second robot, and we are now tracking 2 robots (green and blue) while we experiment with the LED’s and their effectiveness at color detection. It will be a simple matter to expand from 2 to 6 robots, but as we add incremental control functions, we must be sure to make the functions generic. Currently the only functions written and tested are for updating the position of a robot and setting their color. Code to move a robot to a specific coordinate is written but untested because of our inability to track the robots. The majority of our work now is being directed toward better tracking algorithms.
By Chris on December 9, 2010
It seems that colored paper varies in RGB intensities widely across the board, due both to different lighting conditions from the 2 fluorescent lights above our board and from the varying distance of the robot to the CMUcam. We attempted to use LED’s for identification but the LED’s flood the sensors of the camera and don’t provide enough distinction in color across the sensors to be viable. One solution could be to use the LED’s in the dark, diffuse them, and play the robosoccer in the dark. Tube Christmas lighting could be used to line the edges of the rink, and a glow in the dark ball could be used.
EDIT: This works awesome in the dark, with great detection. The camera does a much better job with detecting the color of emitted light, rather than reflected light, as the emitted light is always at the same frequency. If we can make the LED’s more powerful and diffuse them better, this could work in the light.
By Chris on December 8, 2010
In order to better manage the variables and data of our robots, a struct was created for the robot. properties include x and y position, dx and dy to show the movement, angle to show direction the robot is moving in, and node number to identify which firefly node the robot will belong to. This should make it much easier to control the flow of the game and manage the data.
By Chris on December 5, 2010
Q1: AAAHHHhhh! We’re spazzing because we can’t get the #%*$@&! camera to do anything. What do we do?
By Sam on November 16, 2010
One important aspect of this project will be communication between the FireFly nodes and their respective 3pi hosts. This requires knowledge of both APIs, although it is made simpler by the fact that in our implementation communication is one-way. Since the 3pi hosts will essentially be “dumb” recipients of velocity inputs, the communication will only travel from the FireFly nodes to the 3pi robots. The FireFly nodes in turn will only act as repeaters, relaying velocity data from the “coach” to the “players.” Most of the calculations and processing will take place on the CMUcam and “coach” FireFly node.
On the 3pi, communication will take place over the UART digital pin 1 (PD1). On the FireFly, communication will take place over the UART0 pin. Since the red LED on the 3pi is also connected to pin 1, the LED will act as a convenient activity notification for easier debugging.