CSci 5551 Fall 2009

Volkan,
For the project final demos, can you come to the robotics lab any day at a specified time to view my group's final demo(b/w Dec 10-15);evenings will be preferable? Or will a video blog post be acceptable?
Also, for the term paper presentations, does the 20 minute alloted time include time for questions & answers? Will you be allowing any questions from the class for the presenters? And do you want the presentation to be a mirror image of the phase 3 report?

Volkan,
For the project final demos, can you come to the robotics lab any day at a specified time to view my group's final demo(b/w Dec 10-15);evenings will be preferable? Or will a video blog post be acceptable?
Also, for the term paper presentations, does the 20 minute alloted time include time for questions & answers? Will you be allowing any questions from the class for the presenters? And do you want the presentation to be a mirror image of the phase 3 report?

An RA-02 six-servomotor robotic arm and the servomotor controller board based on the PIC16F673 microcontroller were assembled yesterday for our project. The assembly pictures and a brief operational test video are given below.

1) Component Mounting on PCB

2) Putting together the arm

3) Post assembly testing of the arm

UPDATE: This video demonstrates the robotic arm's motion under manual control. We are currently working on automating the process.

Nick Wertzberger and I completed the extra credit for homework 2. Code was uploaded to the pioneer laptop and configured to run for the machine. Swivel speed and distance from obstacles had to be modified several times so that the robot would not spin too fast or get too close to an object before turning.

The first video is in the lab successfully navigating obstacles that are placed.
Note: the clicking noises are from my camera, not the robot.

The second video is showing a true wall-follower. The robot oscillates between its proximity to the wall, but doesn't exceed 1.5 meters.

Thanks for watching!

Modifications to the code and config file were made as per what I read on this blog, and from what I discovered via Google search.

With no prior knowledge/experience with the Pioneer setup, I was initially shooting arrows in the dark, trying to determine why the robot won't move. In all, 4 pioneers were looked at. 2 were out of charge, and the other 2 were not ready to communicate most of the times, making life not so easy!

It was then discovered that the serial/USB adapter was not working correctly. During most of my attempts, only one port's green STATUS LED was on, indiciating that one serial port was not working. "ioctl()" errors at the terminal, similar to the one shown below can be expected in such a case,

After discovering this issue, I suspected that the Pioneer was low on power, and I thus left it for charging for a while.

USB port numbers were verified using "dmesg" to ensure that I had connected the robot to the correct USB port.

After the robot was charged, I attempted to connect to it again, and to my pleasant surprise, the Pioneer sprang to life, but only for a brief time, at the end of which it hit an obstacle and decided to go into it's slumber for the evening.

Since I was initially trying to understand the difference in operation between Stage and the Pioneer robot, I wasn't focused on taking a video of the robot's motion.

I noticed the following,

1) The turn speeds setting needs to be less aggressive when compared to the Stage simulation. Inertia causes the robot to overshoot the point where it should stop turning, so a slow turning speed is desirable, or PID control should be employed.

As an example of the overshoot, the robot was given a command to turn 109 degrees approx wrt the robot's initial yaw. At a turn speed value of 1 in pp.SetSpeed(0,1), the robot ended up turning all the way to 170-180 degrees.

Conclusion : A slower turn speed would have helped keep the robot's degrees of turn more predictable

2) The laser rangefinder doesn't seem to recognize obstacles close to it, even if they are right in front of it! During the brief time when the Pioneers chose to move, the rangefinder would have to be atleast 3ft from the obstacle to detect the obstacle.

Conclusion : Don't assume your rangefinder will work as perfectly as in the simulation

3) I tried a test case of keeping the robot surrounded by obstacles, so that it may just go around in a circle while attempting to get out of the way.

However, this is probably when the battery voltage level went below what was required to operate the rangefinder, and at the same time, the USB/232 adapter decided to sleep, so the robot did not move and starting giving out the same "ioctl()" error.

Conclusion : Time to go home...

================================================

Update!!

The communication problem was solved ... not entirely by me. Thanks to everyone whom I had a conversation with, about the problem.

Steps followed to deploy the BUG-2 algorithm on the pioneer robot are as listed below,

1) Modify the configuration file (.cfg) to remove STAGE and add PIONEER and SICK Laser-rangefinder for the purpose of this trial

2) Motor and odometry setup methods from Class Position2dproxy were used

3) Turn speed value, distance from wall values, etc were determined with trial and error policy, with reference to the inertia issues I had highlighted in my post above. A simple case of turn speed being too high is shown below.

The robot still tries to follow the wall, but the distance from wall was too low in the code to allow it to go past the second attempt at following the wall.

4) Destination coordinates were modifed to test a simple obstacle avoidance case. Video is shown below.

5) With turn speed and wall distance values modified to suit the environment, a case of the robot going from Point-A to Point-B was tested.

Here, I stood right next to the destination point to see if the robot would go around me and still reach the destination...and it did!! :)

Here's a video for the extra credit done by myself and Saurabh. There's a narration, but track turned out a little quiet, so you might need to turn up the volume.

-Konrad

I don't understand what are we supposed to prove in this. Answer is written below it .. one line thing...

I am looking at the problem where bolt position and orientation needs to be described with respect to manipulator's hand.

Thanks
Saurabh

I don't understand what are we supposed to prove in this. Answer is written below it .. one line thing...

I am looking at the problem where bolt position and orientation needs to be described with respect to manipulator's hand.

Thanks
Saurabh

It was way more difficult and frustrating then we (Me and Konrad) initially thought.
The major problems and issues that we faced are summarized below:

1. Specifying laser driver in .cfg file
We had to change the .cfg file for player. We specified laser driver information for pioneer.

driver (
name "sicklms200"
provides ["laser:0"]
port "/dev/ttyUSB1"
}

2. Timeout problem: Laser takes time in starting and activating sensors. It starts in red light mode and one should not start executable until it turns green otherwise it throw timeout.

3. Serial port issues:
Identifying which port on serial device took a lot of our time. Some port on device were not reading values so we had to change the ports on serial device. Generally laser is /dev/ttyUSB1 and robot is /dev/ttyUSB0

4. Inserting the USB in correct USB port: because one USB port is for serial tty/USB0 - tty/USB3 and other is for 4 to 7. We were ignorant on this and were plugging pioneer's USB cable to any of the laptop's USB port but when it started throwing errors and program did not work, we realized this.

5. Robot battery low: some time output is not returned or robot was not able to move further..
We suspected this to be low battery issue.
Make sure battery is well above 10V for smooth functioning.

6. Software related measurement issues and error correction:

a. Rotating more than desired angle:
so for this we had to decrease the turnrate as it was reaching near to desired rotation value... also after it stops rotating we were checking if we need to rotate in opposite direction to get the exact rotation...

b. Laser not returning data and some time data is not that accurate

c. On stage things are simple but pioneer was behaving in very erratic way due to extra rotation and movement related problem. we had a success rate of 66% in our case when robot follows the wall accurately.

d. Path on stage was way different from actual pioneer because actual pioneer had lot of extra rotation and moves beyond the point. On stage it was more smooth path than on actual pioneer. We calibrated lot of variables in movement related to exact positioning and used those error correction parameters in the code.

so for example... while checking slope or distance from a point... we had to use some error value and anything lying between expected output +/- error value was taken as right value or condition fulfillment.

After all this, our robot does not work correctly in all the scenarios but it executes the wall following well in most of the cases and reach to destination lying around the corner.

Space issue:
There was never enough space to carry out this experiment. even if we take obstacle or wall detection distance to 1.0 meter then robot starts sensing other things

If we give less than 1.0M then robot some time gets too close to the wall and while rotating and moving further, it collides with the wall..

To be continued...
Saurabh

Hello, I was wondering if anyone else is having this issue. I'm trying to run the make file on a ubuntu machine 9.10 and get an error status:

/usr/bin/ld: cannot find -lboost_signals
collect2: ld returned 1 exit status
make: *** [demo] Error 1

I have installed the required libraries that are given in the make file and am still running into this issue. If anyone has any ideas on what lib -lboost_signals is in and how to get this resolved I would greatly appreciate it.

~Daniel