Robotics Club: Issueshttps://roboticsclub.org/redmine/https://roboticsclub.org/redmine/redmine/favicon.ico2014-03-31T21:40:32ZRobotics Club
Redmine RoboBuggy - Bug #2233 (Assigned): Write a SURG Granthttps://roboticsclub.org/redmine/issues/22332014-03-31T21:40:32ZMatthew SebekColony Scout - Bug #2121 (Assigned): File Error Service callhttps://roboticsclub.org/redmine/issues/21212012-11-16T23:12:50ZHui Jun Tay
<p>viki@c3po:~/ros_workspace/scoutos/scout/scoutsim$ rosservice call /scout1/sonar_set_scan 5 10<br />ack: True<br />viki@c3po:~/ros_workspace/scoutos/scout/scoutsim$ rosservice call /scout1/sonar_toggle true<br />ack: True<br />viki@c3po:~/ros_workspace/scoutos/scout/scoutsim$ rosservice call /scout1/sonar_toggle false<br />ack: True<br />Unhandled exception in thread started by <bound method TCPServer.run of <rospy.impl.tcpros_base.TCPServer object at 0x923f24c>><br />Traceback (most recent call last):<br /> File "/opt/ros/fuerte/lib/python2.7/dist-packages/rospy/impl/tcpros_base.py", line 156, in run<br /> (client_sock, client_addr) = self.server_sock.accept()<br /> File "/usr/lib/python2.7/socket.py", line 202, in accept<br /> sock, addr = self._sock.accept()<br /> File "/usr/lib/python2.7/socket.py", line 170, in _dummy<br /> raise error(EBADF, 'Bad file descriptor')<br />socket.error: [Errno 9] Bad file descriptor<br />viki@c3po:~/ros_workspace/scoutos/scout/scoutsim$ rosservice call /scout1/sonar_toggle true<br />ack: True<br />Unhandled exception in thread started by <bound method TCPServer.run of <rospy.impl.tcpros_base.TCPServer object at 0x9b2334c>><br />Traceback (most recent call last):<br /> File "/opt/ros/fuerte/lib/python2.7/dist-packages/rospy/impl/tcpros_base.py", line 156, in run<br /> (client_sock, client_addr) = self.server_sock.accept()<br /> File "/usr/lib/python2.7/socket.py", line 202, in accept<br /> sock, addr = self._sock.accept()<br /> File "/usr/lib/python2.7/socket.py", line 170, in _dummy<br /> raise error(EBADF, 'Bad file descriptor')<br />socket.error: [Errno 9] Bad file descriptor</p> Colony Scout - Bug #2110 (Assigned): BOM returns values even when IR LED cannot possibly permeate...https://roboticsclub.org/redmine/issues/21102012-11-11T19:56:41ZJulian Binder
<p>Tested by covering with hand and by enclosing in ESD bag. <br />Checked with camera to make sure IR LED was not visible.</p> Colony Scout - Bug #2109 (Assigned): Add Fuel Guage and Protection circuit to charge boardhttps://roboticsclub.org/redmine/issues/21092012-11-11T06:39:03ZJulian Binder
<p>Protection Circuits Here:<br /><a class="external" href="http://www.sii-ic.com/en/param_chrt.jsp?subcatID=5">http://www.sii-ic.com/en/param_chrt.jsp?subcatID=5</a><br />Fuel Gauge Circuit Here:<br /><a class="external" href="http://www.maximintegrated.com/datasheet/index.mvp/id/5361">http://www.maximintegrated.com/datasheet/index.mvp/id/5361</a></p> Colony Scout - Bug #1878 (Assigned): Cliff Detectionhttps://roboticsclub.org/redmine/issues/18782011-10-26T20:44:20ZPriyanka Deo
<p>Detect Cliffs. Control Motors.</p> Colony Scout - Bug #1807 (Assigned): Website Work Loghttps://roboticsclub.org/redmine/issues/18072011-10-12T14:09:41ZDan Shopedshope@andrew.cmu.edu
<p><del>Add pictures to the sensors & comm page on <a class="external" href="http://www.colonyscout.com">www.colonyscout.com</a></del></p>
<p><del>Default mode for sensors should be expanded, not collapsed.</del></p>
<p><del>Add contact page back to main navigation, or add comment section to "applications" page</del></p> Colony - Bug #1574 (Assigned): wl_basic_do_default(int *length) doesn't set *length to zero if no...https://roboticsclub.org/redmine/issues/15742010-11-12T02:37:38ZAlexander Lamazl@andrew.cmu.edu
<p>Either need to add code to preset &dataLength = 0 in /home/lama/projects/colony/trunk/code/projects/traffic_navigation/main.c (rev 1867) before calling wl_basic_do_default, or change wireless lib to set *length to zero.</p> Colony Scout - Bug #1547 (Assigned): Fix Encoder pinout on breakflyhttps://roboticsclub.org/redmine/issues/15472010-11-01T20:18:49ZDan Shopedshope@andrew.cmu.edu
<p>Breakfly encoders 2 & 3 have completely different pinouts. These should be changed to match or at least be mirror images - will require board re-routing</p> Tooltron - Bug #1363 (Assigned): Tooltron status indicatorhttps://roboticsclub.org/redmine/issues/13632010-05-20T19:53:30ZBrad Neuman
<p>There should be some way of indicating if tooltron is working. There should be something on the website and a physical LED or something on the cardbox or nearby to indicate if the system is up and running.</p>
<p>If tooltron is stopped using the daemon, this should be reflected using this system. There could also be some kind of periodic signal or something sent to the cardbox that tells people tooltron is alive.</p>
<p>We need this so people can tell the difference between not having access and tooltron being down, also in case its down due to maintenance (like reprogramming one of the tools).</p> Tooltron - Bug #1346 (Assigned): timeouts not working correctlyhttps://roboticsclub.org/redmine/issues/13462010-05-10T22:10:08ZBrad Neuman
<p>It seems like the cardbox sometimes skips the timeout state, after going yellow it just turns off instead of doing red or green</p> Tooltron - Bug #1327 (Assigned): Server dies when internet is outhttps://roboticsclub.org/redmine/issues/13272010-04-24T22:25:43ZKevin Woo
<p>The server dies when the internet goes out necessitating the manual override of tools. This may be a security hole but perhaps we should enable all tools when people swipe if the internet goes out and the mysql server can't be accessed. That way it will be transparent to users.</p> Tooltron - Bug #1197 (Assigned): Keypad row 3 (7,8,9,C) does not workhttps://roboticsclub.org/redmine/issues/11972010-03-27T18:47:26ZBrad Neuman
<p>The keypad isn't busted (we probed the leads and saw that rows were connected) but we don't get anything from row 3.</p>
<p>We tried adding delay_ms calls after setting the DDRs in the get button code and that didn't help.</p>
<p>This isn't very critical because these buttons will never be used, but still.</p> Colony - Bug #960 (Assigned): xbee idhttps://roboticsclub.org/redmine/issues/9602009-12-05T07:05:22ZDavid Schultzdsschult@andrew.cmu.edu
<p>The xbee id should be set to the robot id (which is in the eeprom) on init.</p>
<p>The xbee currently just uses the last stored address in xbee memory, which works most of the time but is not failsafe.</p> Colony - Bug #852 (Assigned): Xbee Documentationhttps://roboticsclub.org/redmine/issues/8522009-10-30T19:41:35ZDan Shopedshope@andrew.cmu.edu
<p>Make a page on wiki w/ Xbee setup/config commands</p>
<p>Link to PDF</p> Colony - Bug #790 (Assigned): XBee/Wireless Initializationhttps://roboticsclub.org/redmine/issues/7902009-10-20T01:38:01ZJohn Sextonjsexton@alumni.cmu.edu
<p>XBee and Wireless Init functions seem to conflict. dragonfly_init() appears to call xbee_init() [found in serial.c in libdragonfly], while wl_init() appears to call xbee_lib_init() [found in xbee.c in libwireless]. The two functions appear to be arguing over what to assign a few registers.</p>
<p>We found that to get the XBees to work, xbee_init() needs to be called again after drangonfly_init(), but before wl_basic_init_default() [which basically just calls wl_init()].</p>
<p>We also are not confident that calls to wl_set_channel() are working correctly, or if the channel is getting re-initialized by calls to xbee_init()/xbee_lib_init().</p>