While it may seem obvious, the details, as usual, are the problem and this post over at the Wired Danger Room scratches the surface of some of the legal and ethical issues facing teleoperated robots. I am still unsure why the TLA is the ones flying the drones, but if it keeps them from dealing on the streets at least that's something.
Operators of other armed robots may also find themselves facing charges in the event of a lethal malfunction while in co-op mode. I hope for everyones sake that the robots provide a way to prove if the equipment is or is not being teleoperated and provide a secure means of identifying the operator. At least some of the killbots have finally implemented encryption, so hopefully the inevitable unintended deaths don't result in claims of hacking.
I am sure this will be an ongoing story of unintended consequences.
Thursday, April 29, 2010
Wednesday, April 28, 2010
ArduPilot Mega
The ArduPilot Mega UAV autopilot is finally here, and just in time for flying season. Now that it has enough serial ports, I really should spend some time getting my airplane flying, but as my hobby project I find myself spending most of my time yak shaving and not enough flying. At least the yak shaving has been productive.
Monday, April 26, 2010
RoboChair?
Speaking of improving the lives of children through the use of robotics, this RoboChair, developed by the industrial technology center of SAGA, looks to be designed to provide mobility to handicapped children.
Though at 300,000 - 500,000 yen, it seems somewhat expensive for a device that the child will quickly outgrow.
For some reason, I think this QoLT thing is going to be a big part of robotics work in the future. It should also be slightly safer than working on building killbots.
[From: RoboNable]
Call for Papers: Special Issue on Roboethics
IEEE Robotics and Automation Magazine is having the March 2011 special issue dedicated to Roboethics and has a call for papers up here. The deadline for papers is September 01, 2010.
After watching the movie Hardware again this weekend, I remembered that I wanted to mention this call for papers. I think it is important that the robotics community continues to think critically about the ethical issues involved with robotics. While in the long run the killbots will probably hunt down the last of the human survivors, in the short term the issues are fairly complex and demand serious consideration.
I think I saw a twilight zone episode where all the parents were replaced with robots, this could be our future. Imagine the nutritional improvements that can be made to children's diets. What child would argue with a robot about eating their peas, especially a robot equipped with a 10 KiloVolt synaptic persuader. The robotic guardians would also be able to monitor and enforce critical educational tasks such as homework completion when interfaced with a household wireless mesh sensor network.
While the research is clear the robot guardians can enhance the lives of children who are lucky enough to have parents able to afford robotic supervision, what about those children whose parents are unable to afford such compaionship. Is it ethical to allow children to not be raised by robots?
The Roboethics website may have more information in the future after they recover from being hacked. Possibly by a malignant artificial intelligence. Fortunatly, time travelers have saved a copy of the information in hopes that one day someone can make use of it.
After watching the movie Hardware again this weekend, I remembered that I wanted to mention this call for papers. I think it is important that the robotics community continues to think critically about the ethical issues involved with robotics. While in the long run the killbots will probably hunt down the last of the human survivors, in the short term the issues are fairly complex and demand serious consideration.
I think I saw a twilight zone episode where all the parents were replaced with robots, this could be our future. Imagine the nutritional improvements that can be made to children's diets. What child would argue with a robot about eating their peas, especially a robot equipped with a 10 KiloVolt synaptic persuader. The robotic guardians would also be able to monitor and enforce critical educational tasks such as homework completion when interfaced with a household wireless mesh sensor network.
While the research is clear the robot guardians can enhance the lives of children who are lucky enough to have parents able to afford robotic supervision, what about those children whose parents are unable to afford such compaionship. Is it ethical to allow children to not be raised by robots?
The Roboethics website may have more information in the future after they recover from being hacked. Possibly by a malignant artificial intelligence. Fortunatly, time travelers have saved a copy of the information in hopes that one day someone can make use of it.
Labels:
Call for Papers,
ethics,
robotics
Friday, April 23, 2010
Magic and other programming tricks
This is some good stuff.
If you program and are unfamiliar with the dangers of floating point, then you should read this. Proper understanding of how floating point actually works is important because sometimes "cos(x) != cos(y) even though x == y".
My personal rule of thumb is that closed source software needs to be at least two orders of magnitude better in performance then the equivalent open source program. Otherwise it is not worth all the hassles. On that note, Octave is a MATLAB replacement that on my list of software to try. Also, unlike MATLAB it can be connected to ROS, which is nice.
On another computational note, I liked the fifth edition of this textbook for an introduction to numerical methods. Which could be useful if you are trying to program complex math(s) on a microcontroller.
Normally, a dual-linked circular list would contain both previous and next pointer fields and the current position in the list would be identified by a single pointer. By using two current pointers, one to the node in question and the other to the one just before/after it, it becomes possible to store only a single pointer value in each node. The value stored in each node is the XOR of the next and previous pointers that normally would have been stored in each node. Decoding is obvious.
If you program and are unfamiliar with the dangers of floating point, then you should read this. Proper understanding of how floating point actually works is important because sometimes "cos(x) != cos(y) even though x == y".
Turns out that the behavior can depend on how many instructions are between the cos() calls and the != comparison.This is another example of the trickery of floating point. Thinking about this, I recently said to a friend of mine, "I'm surprised companies' billing systems ever work", his response was "maybe they don't". Which is kind of disturbing to think about. Though some have claimed that this is why we will be running Cobol code forever.
My personal rule of thumb is that closed source software needs to be at least two orders of magnitude better in performance then the equivalent open source program. Otherwise it is not worth all the hassles. On that note, Octave is a MATLAB replacement that on my list of software to try. Also, unlike MATLAB it can be connected to ROS, which is nice.
On another computational note, I liked the fifth edition of this textbook for an introduction to numerical methods. Which could be useful if you are trying to program complex math(s) on a microcontroller.
Labels:
floating point madness,
programming,
software
Thursday, April 22, 2010
Random Thoughts: Further Testing Needed
In the past, we have covered camera calibration and the effects of autofocus. Now that calibration is easier, it looks like there may be some issues with the positional repeatability of the auto focus lens mechanism. Initial results seem to indicate that every time the focus of the camera changes not only does the focal length change but it looks like the orientation of the primary axis and position of the center of the lens relative to the principal point also change.
A little more testing is need but the long and the short of it is that the Logitech Quickcam 9000 may not be useful for many computer vision applications since you may not be able to rectify the image consistently unless you recalibrate the camera every time the focus changes. A lookup table won't work since you have no way of determining how the orientation of the lens has changed.
Oh and that auto focus mechanism, it's an electromagnet. As we have previously noted, magnetic fields have some implications for inertial navigation. One thought I had today was that often the intensity of the magnetic field is ignored because generally the strength of the Earth's magnetic field is constant and you are only looking to determine the orientation relative to magnetic north.
Perhaps the covariance for the Kalman filter could be weighted based on the magnetic field strength relative to the nominal field strength of the Earth. That way, if there is magnetic interference, the sensor readings from the magnetometer will have less influence on the output. Maybe someone else has researched this problem.
A little more testing is need but the long and the short of it is that the Logitech Quickcam 9000 may not be useful for many computer vision applications since you may not be able to rectify the image consistently unless you recalibrate the camera every time the focus changes. A lookup table won't work since you have no way of determining how the orientation of the lens has changed.
Oh and that auto focus mechanism, it's an electromagnet. As we have previously noted, magnetic fields have some implications for inertial navigation. One thought I had today was that often the intensity of the magnetic field is ignored because generally the strength of the Earth's magnetic field is constant and you are only looking to determine the orientation relative to magnetic north.
Perhaps the covariance for the Kalman filter could be weighted based on the magnetic field strength relative to the nominal field strength of the Earth. That way, if there is magnetic interference, the sensor readings from the magnetometer will have less influence on the output. Maybe someone else has researched this problem.
Tuesday, April 20, 2010
Another Rovio Driver for ROS
Here is another Rovio driver for ROS. At the moment, this one seems to support a few more features than this driver.
Update: Behold the power of open source software, this apparently fixes the stupid brightness issue on the Rovio.
Update: Behold the power of open source software, this apparently fixes the stupid brightness issue on the Rovio.
Monday, April 19, 2010
Saturday, April 17, 2010
National Robotics Week: Boston Block Party
Reporting in from Boston, the robot block party was in full swing at the Museum of Science.
Students from WPI brought their prize winning Moonraker 2.0 robot. WPI also has an undergraduate major in robotics engineering that may be of interest to readers.
The FIRST robotics team from Massachusetts Academy of Mathematics and Sciences at WPI sent some of their mentors to show off last years robot while they are in Atlanta.
These robotics bugs are from the Harvard Microrobotics Lab.
They are equipped with a flexible backbone and piezo electric actuation.
More information about their research can be found on their website.
Robonica brought some of the Roboni-i to the party.
No robot block party in Boston is complete with out Roombas.
The iRobot Packbot was also able to make it to the party.
Barrett Technology brought two robot arms. The arms looked very well built and are equipped with a zero backlash cable drive and custom low power electronics that somehow use less then 28 watts.
Students from Olin College brought one of their student projects built on the Lynxmotion hexpod base.
QinetiQ North America brought one of the Talon robots, a successor to the swords platform. It was fortunate that it was unarmed.
Artaic is a Boston based startup with what looks to be a solid business model. Designed to be compatible with standard installation techniques, their robots can produce low cost tile mosaics.
Nao came by the party to show of its dance moves. Fortunately for Nao we did not have any tools with us so we were unable to get any disassembly photos.
There was also a design challenge for building your own bristlebot.
Kiva Systems also gave a presentation on the order fulfillment system.
At talk by Mike Ciaraldi about "Getting Started in Robotics at Any Age". One of the many great presentations at the block party.
We are already looking forward to the next National Robotics Week.
Labels:
Boston,
National Robotics Week,
Party,
robotics
National Robotics Week: Pittsburgh
Arriving at CMU we checked in with "Tank" the roboceptionist and then it was off to the races.
The view from the finish line shows the challenge facing today's racers.
The crowds were out in PGH for race day at Carnegie Mellon University School of Computer Science's 24th Annual Mobot Races. The weather was beautiful but challenging for the line followers with bright sunshine and passing clouds.
The mobots were equipped with sensors ranging from infrared color sensors to webcams doing line detection in OpenCV.
Some were equipped with sensors to detect the gates for navigating the course.
Passing clouds caused issues for mobots using IR sensors for line detection.
This one uses Roomba motors for its drive system. The Roomba is a good source of robot parts for roboticists on a budget.
After the race, the red robot from the CMU Robotics Club invited us back for a tour of their lab...
...where the club was providing a post-race musical performance.
The drummer was definitely rocking out. Video update to come.
Here is one of the Colony robots, part of the club's swarm research.
A work in progress, the robot air hockey table look like another way robots will crush the human spirit in the future. When completed its performance should be on par with this one.
A stair climbing robot under development. In the future the stairs will provide no means of escaping our future robot overlords.
A special thanks to DanShope.com for giving us a tour of the club's facilities.
We headed out, waving goodbye Sid.
The Robotics Institute has been a pretty busy place for the last 30 years.
Before heading off to our next stop, we were able to catch a talk by Matt Mason the director of the Robotics Institute on the history of the Robotics Institute.
See you in Boston!
The view from the finish line shows the challenge facing today's racers.
The crowds were out in PGH for race day at Carnegie Mellon University School of Computer Science's 24th Annual Mobot Races. The weather was beautiful but challenging for the line followers with bright sunshine and passing clouds.
The mobots were equipped with sensors ranging from infrared color sensors to webcams doing line detection in OpenCV.
Some were equipped with sensors to detect the gates for navigating the course.
Passing clouds caused issues for mobots using IR sensors for line detection.
This one uses Roomba motors for its drive system. The Roomba is a good source of robot parts for roboticists on a budget.
After the race, the red robot from the CMU Robotics Club invited us back for a tour of their lab...
...where the club was providing a post-race musical performance.
The drummer was definitely rocking out. Video update to come.
Here is one of the Colony robots, part of the club's swarm research.
A work in progress, the robot air hockey table look like another way robots will crush the human spirit in the future. When completed its performance should be on par with this one.
A stair climbing robot under development. In the future the stairs will provide no means of escaping our future robot overlords.
A special thanks to DanShope.com for giving us a tour of the club's facilities.
We headed out, waving goodbye Sid.
The Robotics Institute has been a pretty busy place for the last 30 years.
Before heading off to our next stop, we were able to catch a talk by Matt Mason the director of the Robotics Institute on the history of the Robotics Institute.
See you in Boston!
Labels:
CMU Robotics Club,
Mobots,
Music,
National Robotics Week,
PGH
Friday, April 16, 2010
National Robotics Week: Stanford Robot Block Party
Willow garage has photos up from the Standford Block Party.
We will have more coverage of the National Robotics Week events uploaded after we catch this flight.
Labels:
National Robotics Week,
Party,
robotics
Thursday, April 15, 2010
Thing-a-Week #8: Small Camera Servo Mount
This weeks thing is a servo mount for the Point Grey Flea2 and Chameleon Cameras. These cameras are fairly popular for robotics since they have a global shutter which is often critical for machine vision tasks.
This can be used to provide pan or tilt control of the camera with an standard servo. In this case a Hi-Tec HS-325HB servo has sufficient torque to accurately position the camera.
The mounting plate can be connected to the servo using M1.6 screws or M2x6mm screws with nuts. You could probably modify the design to work with imperial sizes if you wanted to.
The M1.6 screws are inserted from the top into the servo horn. The servo horn does not need to be tapped to securly hold the screws.
Using M2 screws will require first drilling out the holes in the servo horn.
The top of the mounting plate provides hexagonal holes that are designed to hold the nuts and keep them from rotating.
Here is the camera setup to pan left to right using the servo.
get a better view of how the parts fit together. The servo was testing in tilt mode and sufficient torque was available to hold the camera steady. Larger or heavier lenses may require a bigger servo.
If you want to try making your own, the part files, as always, are available at Thingiverse and if you don't a have a 3D printer you can buy the mounting plate here.
This can be used to provide pan or tilt control of the camera with an standard servo. In this case a Hi-Tec HS-325HB servo has sufficient torque to accurately position the camera.
The mounting plate can be connected to the servo using M1.6 screws or M2x6mm screws with nuts. You could probably modify the design to work with imperial sizes if you wanted to.
The M1.6 screws are inserted from the top into the servo horn. The servo horn does not need to be tapped to securly hold the screws.
Using M2 screws will require first drilling out the holes in the servo horn.
The top of the mounting plate provides hexagonal holes that are designed to hold the nuts and keep them from rotating.
Here is the camera setup to pan left to right using the servo.
get a better view of how the parts fit together. The servo was testing in tilt mode and sufficient torque was available to hold the camera steady. Larger or heavier lenses may require a bigger servo.
If you want to try making your own, the part files, as always, are available at Thingiverse and if you don't a have a 3D printer you can buy the mounting plate here.
Labels:
3D Printer,
projects,
thing-a-week
Wednesday, April 14, 2010
Tuesday, April 13, 2010
Scheduler Overload
Things are a bit busy, so this will be a quick and random update.
I Heart Robotics is getting ready for the rest of Robotics week and will have updates later this week. Are you ready?
In other news, OpenCV 2.1 has been released. I'll have to check if the circle detection issue is fixed.
The Canon SX120 CHDK driver is in beta, it sorta works now. But no HDR robot pictures yet.
I don't normally bleg, but if anyone has access to the Arm ADS 1.2 Compiler, we could use some help over here.
This display might be interesting for a ground station if it really is sunlight readable.
holypongは一番づすよ!
I Heart Robotics is getting ready for the rest of Robotics week and will have updates later this week. Are you ready?
In other news, OpenCV 2.1 has been released. I'll have to check if the circle detection issue is fixed.
The Canon SX120 CHDK driver is in beta, it sorta works now. But no HDR robot pictures yet.
I don't normally bleg, but if anyone has access to the Arm ADS 1.2 Compiler, we could use some help over here.
This display might be interesting for a ground station if it really is sunlight readable.
holypongは一番づすよ!
Sunday, April 11, 2010
Friday, April 9, 2010
Rovio Source Code!
I am cautiously optimistic, but it looks like WowWee has done the right thing and released source code to the Rovio.
I'll have an update this weekend after I either brick the Rovio or manage a successful build.
I'll have an update this weekend after I either brick the Rovio or manage a successful build.
Labels:
GPL,
Rovio,
Rovio Hacking,
software
MicroMouse Lattice Points
Canonboy3 from Hotproceed in Japan came up with this great idea for
those of us with poor woodworking skills. Each lattice point holds up the connected walls and takes only 19 minutes to make. More MicroMouse info here and here.
Update: Now it is up on thingiverse! ありがと !
Labels:
3D Printer,
japan,
micromouse
Wednesday, April 7, 2010
Playback: Now in HD
The I Heart Robotics website has been upgraded to HD for an improved viewing experience. Comments and complaints are welcome,but if you are browsing on a mobile device you may want to consider our RSS feed.
The PixHawk Team shows off their ground station software.
More cellbots, now with autonomous action and less falling off the table.
This video reminds me of this image, for some reason.
The PixHawk Team shows off their ground station software.
More cellbots, now with autonomous action and less falling off the table.
This video reminds me of this image, for some reason.
Labels:
cellbots,
ground station,
PixHawk,
Playback,
video
No rest for the PR2s
Willow Garage now claims that they consider sleep unnecessary. We agree, if you don't sleep you can get three days work done each regular day. This greatly increases productivity while only costing 1D4 sanity if you miss your saving throw.
Labels:
batteries,
No Sleep,
Power management,
PR2,
willow garage
Tuesday, April 6, 2010
Roomba 4000 Teardown
Dino Segovis is at it again with a series of videos showing you how to get to the candy center of the Roomba.
Labels:
dissection,
irobot,
Roomba,
video
Monday, April 5, 2010
A Case for Arduino: Bamboo Cutouts
Here are some of the test versions of the end plates for the case.
More information about the Arduino Case design project can be found here.
Untreated laser cut bamboo panel.
The same panel after being stained and a light polyurethane coat.
While the bamboo is 100% renewable, I'm not sure how green it actually is once you consider the glue, stain, and polyurethane. Regardless, I still think it looks beautiful.
More information about the Arduino Case design project can be found here.
Untreated laser cut bamboo panel.
The same panel after being stained and a light polyurethane coat.
While the bamboo is 100% renewable, I'm not sure how green it actually is once you consider the glue, stain, and polyurethane. Regardless, I still think it looks beautiful.
Labels:
A Case,
arduino,
case,
design ideas,
mechanical,
projects
Friday, April 2, 2010
Thing-a-Week #7: Rovio Laser Scanner
Due to certain issues, it is currently difficult to add new sensors to the Rovio. One way around the problem is to use the sensors the Rovio comes with in a new way.
Using some 3D printed parts and a 12mm diameter $15 laser line generator from eBay you can make a basic laser scanner. This is based on the laser scanner design from Kenneth Maxon. It uses the 3mm version (Part # 3BT-P8003-00) of the screws that were tested here.
Here is a picture from the Rovio.
This video shows playback of the data recorded into a ROS bag file. The file contains the timestamped image data and commands sent to the robot.
The laser's focus seems less than ideal, and the focus adjustment ring keeps coming loose despite the addition of teflon tape. I have not tried image processing the results yet but I am going to guess that filtering out the line may prove to be difficult. Using an infrared laser and a camera equipped with an IR bandpass filter would probably make image processing signifigantly easier but that would kind of defeat the point of modifying the Rovio. Converting the image data into a 2D laser scan in ROS using OpenCV should be fairly straightforward but will be left as an adventure for another day.
It looks like the concept could work, but practical details may limit its usefulness. If you want to try making your own, the part files, as always, are available at Thingiverse.
Using some 3D printed parts and a 12mm diameter $15 laser line generator from eBay you can make a basic laser scanner. This is based on the laser scanner design from Kenneth Maxon. It uses the 3mm version (Part # 3BT-P8003-00) of the screws that were tested here.
Here is a picture from the Rovio.
This video shows playback of the data recorded into a ROS bag file. The file contains the timestamped image data and commands sent to the robot.
The laser's focus seems less than ideal, and the focus adjustment ring keeps coming loose despite the addition of teflon tape. I have not tried image processing the results yet but I am going to guess that filtering out the line may prove to be difficult. Using an infrared laser and a camera equipped with an IR bandpass filter would probably make image processing signifigantly easier but that would kind of defeat the point of modifying the Rovio. Converting the image data into a 2D laser scan in ROS using OpenCV should be fairly straightforward but will be left as an adventure for another day.
It looks like the concept could work, but practical details may limit its usefulness. If you want to try making your own, the part files, as always, are available at Thingiverse.
Labels:
projects,
ROS,
Rovio,
Rovio Hacking,
software,
thing-a-week
Subscribe to:
Posts (Atom)