Huge Progress! February 15, 2014

We’ve made great progress in the cleaning up of PR2Lite into its final configuration.

  • Replacing the old desktop-based computer with its converter with a laptop went a long way to clean up the wiring.
  • We added a shelf for the laptop above the microcontrollers for the linear actuator and wheel pids.
  • The wires now go up in a channel cut into the shelves per its original design.
  • In the shelf above the laptop, we put the new DC to AC converter, all the AC adapters (e.g., for the neato the usb hubs, the dynamixels, the kinect), and two powered USB3 Hubs for all the USB-based controllers.
  • the next shelf up has three 12v SLA to power the DC to AC adapters.  It also holds the joystick.
  • The top shelf has the neato board and some battery voltage level detectors.
  • The dynamixel CM-5 and USB2Dynamixel were moved down within the moving outer torso.
  • The Linear actuator holders for the torso up/down were re-glued.
  • Courtesy of excellent Robotis customer service, our new MX-106/MX-64/Velo gripper arm is operational again.

We are currently upgrading the encoders for the wheels and continue to improve the mobility of the base.

Mobile

Pictures of PR2Lite, which now doesn’t need to be plugged into an outlet to run!

PR2Lite's arm moving (It planned out it's movements -- see the laptop screen)

PR2Lite’s arm moving (It planned out it’s movements — see the laptop screen)

January 2014 Update: PR2Lite moves real arm with Moveit!

PR2Lite has completed its initial migration to Hydro and Moveit! with the help of its new laptop.

The migration after the fix for the mimic joints was installed went smoothly.  The integrated support of moveit with the higher level planner, the lower level planner, rviz, fake joints, mimic joints, the setup assistant, the configuration files, and more makes support for non-PR2 robots much simpler than the older arm navigation in ROS Electric. Having already gone through the learning pains and building some of the necessary infrastructure to get a working arm-navigation from ROS Electric definitely helped the migration go well. Some of the old PR2Lite custom configuration files and PR2Lite controllers overlap the newly provided generic functionality provided by Moveit, but it doesn’t seem to cause any operational issues and provides some improved flexibility at a cost of increased configuration complexity. Including the torso lift as part of PR2Lite’s arm navigation results in much better plans.

In summary, we wish Moveit! had been around a few years ago.

The pr2lite_moveit_config and moveit_pr2lite code for arm navigation has been uploaded to git_hub:
https://github.com/rqou/prlite-pc

We are now beginning a phase of cleaning up of PR2Lite:
  • replace the old  desktop-based computer with its cumbersome DC-AC converter with the nicer laptop
  • We currently rely mostly on a tethered robot.  We’re about to change that to improve pr2lite mobility.  Unlike the current configuration, we’ll make it easy to be able between switch from battery power and tethered power.  To accomplish this, we’ll use a new DC-AC converter to power the following components that need either a wall-adapter or additional power:
    • the Laptop power adapter
    • the USB power for the hikuyo lidar
    • powered USB3/USB2 hubs for the IMU and microtrollers
    • the power chord of the kinect
    • the power for the Dynamixel servos
    • the power adapter for the neato lidar
    • wireless hub
  • The wheels and the linear actuators will have their own dedicated batteries.
  • add low-battery alarms to avoid silent errors with our linear actuator and wheel drivers
  • clean up the wire mess.
  • continue to improve the reliability of the microcontrollers
  • upgrade the resolution of the wheel encoders

In parallel, we’ll continue to test 2D navigation (hydro version not yet checked in), the new MX-based arm, and more.

Robotics Club Tabletop Challenge 3

Here’s the code from our last meeting, a currently incomplete tabletop robot that currently only locates the tissue box.

————————————————-

void goForward (){
startMotor (wheelr, 90);
startMotor (wheell, 70);
}

void stopMotors(){
stopMotor (wheelr);
stopMotor (wheell);
}

void goBackwards(){
startMotor (wheell, -70);
startMotor (wheelr, -70);
}

void turnCCW(){
int motorRTurn = SensorValue(encoderr);
int motorLTurn = SensorValue(encoderl);

startMotor (wheelr, 75);
startMotor (wheell, -50);

while (SensorValue(encoderr) – motorRTurn < 365 && SensorValue(encoderl) – motorLTurn < 301)
{
}

stopMotor(wheell);
stopMotor(wheelr);
}

void turnCW(){
int motorRTurn = SensorValue(encoderr);
int motorLTurn = SensorValue(encoderl);

startMotor (wheelr, -75);
startMotor (wheell, 60);

while (SensorValue(encoderr) – motorRTurn < 395 && SensorValue(encoderl) – motorLTurn < 395)
{
}

stopMotor(wheell);
stopMotor(wheelr);
}

task main()
{
while(SensorValue(sonar)>= 20){
goForward ();
}
wait (.5);
turnCW ();
goForward ();
wait (4.9);

}

Moveit breakthrough with PR2Lite

Update from Alan.

We’re taking a break from formal meetings in December.  Alex and his son will continue experimenting with ROS on the Neato.  Alan is continuing his work on PR2Lite arm navigation and has made a nice breakthrough.

We’re updating arm navigation in the following ways:

  • New right arm configuration with MX-64s, MX-106s, and the velo gripper
  • using Moveit on Hydro on the latest Ubuntu release
  • using a new laptop

The newest Ubuntu release required some minor code changes to get hydro to compile.

The tutorials were not quite accurate.  Using the configuration in pr2_moveit_config as a starting point helped.

Moveit on Hydro doesn’t officially support mimic links when launching demo.launch.  Some hacks allowed progress to be made, but Alan was encountering bugs, especially in kdl_kinematics_plugin.  After fixing some problems, Alan found the following commit by Ioan Sucan andSachin Chitta in the Hydro development branch:

Pulling in a subset of the changes to the laptop fixed many of the bugs Alan was encountering.  The arm navigation in demo.launch seems to hit problems in some edge conditions, but the new arm navigation may now be usable.  A major breakthrough.

Next, we need to change some of the hardware configuration on the physical robot to allow the laptop to replace the existing computer.

Robotics Club Tabletop Challenge #2

On Wednesday, Nov. 11, Robotics Club had an after-school meeting to work on part 2 of the HBRC Tabletop Challenge.  The rules for that were to cross from one side of the table to the other, and come back to the original side without falling off the table.  Three groups programmed code, and all groups got their code working well within the hour.  This was good for their first autonomous programming.

Here are the three programs they wrote to all achieve the same goal:

//PROGRAM #1
void motorForward() {
startMotor (MotorR, 125);
startMotor (MotorL, 125);
}

void motorBackward () {
startMotor (MotorR, -100);
startMotor (MotorL, -78);
}

void StopMotor () {
stopMotor (MotorR);
stopMotor (MotorL);
}

void detectEdge1() {
while(SensorValue(LimitL1) == 1 && SensorValue(LimitR1) == 1) {
wait(0.01);
}
motorBackward();
}

void detectEdge2 () {
while(SensorValue(LimitL2) == 1 && SensorValue (LimitR2) == 1) {
wait(0.01);
}
motorForward();
}

task main () {
motorForward ();
detectEdge1 ();
detectEdge2 ();
motorForward ();
wait (2);
StopMotor ();
}

//PROGRAM #2
void goforward(){
startMotor(motorR, 100);
startMotor(motorL, 100);
}

void edgeDetect()
{
int x = 1;
while (x == 1){
if (SensorValue(a)==0){
stopMotor(motorL);
stopMotor(motorR);
x = 0;
}

if (SensorValue(b)==0){

stopMotor(motorL);
stopMotor(motorR);
x = 0;
}
}
}

void gobackward(){
startMotor(motorR, -100);
startMotor(motorL, -78);
}

void edgeDetect2(){
int x = 1;
while (x == 1){
if (SensorValue(c)==0){
stopMotor(motorL);
stopMotor(motorR);
x = 0;
}
if (SensorValue(d)==0){
stopMotor(motorL);
stopMotor(motorR);
x = 0;
}
}
}

void forward2(){
startMotor(motorR,75);
startMotor(motorL,75);
wait(2);
stopMotor(motorL);
stopMotor(motorR);
}

task main(){
goforward();
edgeDetect();
gobackward();
edgeDetect2();
forward2();
}
//PROGRAM #3
void goForward()
{
startMotor (motorL, 100);
startMotor (motorR, 100);
}

void goBackward ()
{
startMotor (motorL, -100);
startMotor (motorR, -100);
}

task main()
{
while(SensorValue(frontR)==1 && SensorValue(frontL)==1)
{
goForward();
}

while(SensorValue(backR)==1 && SensorValue(backL)==1)
{
goBackward();
}

}

Melonee Wise and Michael Ferguson from Unbounded Robotics demo UBR-1 at HBRC

Alan, Alex and Maxim attended the November HBRC featuring the UBR-1 by Unbounded Robots and presented by Melonee Wise (CEO) and Michael Ferguson (CTO).  Below is Alan’s report.

The HBRC presentation had 3 parts.  First, Melonee gave a nice presentation on the history of robots contrasting real robots vs. the high expectations set by fictional robots.  The presentation featured excellent vintage videos of robots.  In the center section, Melonee did Q&A, which is the focus of the rest of this blog entry. Finally, Michael gave a demo of UBR-1 which is in the following video.  Note that while the base was stationary during the demo, Michael was driving UBR-1 via joystick around the room before the presentation.  Also, the screen on the video is hard to see, but it was displaying the robot model that was moving in sync with the real robot.

The base model for UBR-1 is $35,000.  This price tag is a lot less than the PR2, but still a lot more than PR2Lite cost to build. IEEE Automation had a nice introduction to UBR-1 with a nice follow up interview.

Other news coverage actually called the UBR-1 a PR2-Lite!

The following is a summary of the info from the Q&A.

The UBR-1 has a 7 DOF arm and a 14″ telescopic torso.  It has a 3-D camera similar to a Kinect.  Such a camera cost $10,000 when PR2 was designed.  The PR2’s Batteries (1.2 kilowatts for 2 hours), the custom servers with the first 4 quad-core i7s, and other decisions for the PR2 were not chosen with production at scale in mind.  UBR-1 has the advantage of the latest technology advances and being designed for production.


The UBR-1 has a Laser scanner with a range of 4 to 6 meters at 180 degrees.  Both the 3-D camera and Laser scanner are indoor only.

The arm is 7 DOF with the same joint configuration as PR2.  The UBR-1 has a higher reach (by 3″), a better ground reach, and a longer cross-table reach compared to the PR2 despite having a shorter arm than the PR2.  This is partially due to the greater joint angles and a better base to arm ratio.The UBR-1 arm is designed for low inertia (by minimizing the swinging mass).  The arm design tries to minimize pinch points.  The arms currently use a numerical solver right now, but may move to something faster like OpenRave IKFast.  The arms have a max payload of 1.5 kilograms at full extension.The arm uses active gravity compensation to keep the arm in-place and compliant.  Forward kinematics are used to determine torque.  If the emergency-off button is triggered, then the arms will slowly fall.  Active gravity compensation consumes power, even when the robot is otherwise idle, but it is only 12 watts with the arm straight out.  PR2 used counterbalanced arms, but this comes at a cost of greater weight. (note: the UBR-1 is 160 pounds vs 450 pounds for PR2.) For an active robot, active compensation should be better.

The UBR-1 base model has an i5 server with 8 gig of RAM.  ARM microprocessors are distributed through the robot.  It takes 8 screws to replace the battery. There’s a cable harness down the arm. Driving takes 80-100 watts for the base.  Arm movement consumes 25 watts. The computer consumes up to 60 watts. There are 600 watt hours of battery. Automatic docking to a recharger is supported. Most of the rest of the internals are currently trade secrets.

UBR-1 travels at .75 meters per second.  It has wheel encoders with sub-millimeter accuracy which are fused with IMU sensor data to compensate for slippage.

The UBR-1 is envisioned for the markets including educational/research, light manufacturing (stocking shelves, biomedical), elderly care, and hospitality (room service,  EPG – Evidence of prior guest).  Although UBR-1 can support remote actuation (e.g., through ROS), it has no screen to make it targeted at the telepresence market. Series A funding will be raised soon. The robots should start delivery in the summer of 2014.

Software is based on ROS and MoveIt!  Unbounded Robotics plans to release an open source developers kit.  A gazebo simulation is planned to be released soon, but gazebo is undergoing significant changes due to the DARPA challenge.

Remember when PR2Lite took on Maxwell at Maker Faire to play chess? Well, UBR-1 plays chess too!