I worked primarily on the find algorithm this week using the Stack object in java. I completed and tested the Stack which simply does the negative of whatever the user inputs and thus retraces the steps to the dock.
Problems encountered were that the robot again does not move as fast as it is sent commands and those overlapping commands are lost. This was resolved with a Thread.sleep() command however will be soon changed to a poll of the robot status to determine if moving. This method like others has the problem that running into things causes wheel slippage and the robot is no longer where it thinks it ought to be.
On Thursday I began testing the sonar array for compatibility with a bumper system. This would simply stop the robot if ever it got too close to the walls. It seems that the sonar will work though I have not discovered what limit to place on them. I think if less than 250 will be about right. The bumper class will be another thread that will monitor at all times these sonar inputs. It has been created but currently holds no useful code.
Next week will be further work on the find algorithm and bumper class. Hopefully bumper will be done so that I can work on a smarter find.
Progress has slowed this week with as I prepared for and gave the first presentation and ended up spending some lab hours on that. Tomorrow I hope to change the server to monitor robot battery at all times (currently only monitors when a user is connected) I will also begin creating the move stack in java, I would like some suggestions about what to use here. It seems java would have a class or object that does much of this for me. Stack perhaps??? We are still running on schedule but if we are to meet the find algorithm deadline I will need to move a little quicker.
This week work progressed on the find algorithm. The dexter algorithm was tested
somewhat and found to be as expected very poor. A new plan of attack will be
needed. That will be either the internal map and sonar to locate self on map
or the keep track of location in a stack and then retrace steps. Unfortunately
you and I seem to disagree on what will be best
we will discuss this tomorrow.
The prime focus of this week has been catching up on documentation and getting
reading for the project review on Thursday 2/21/02. Errors with string.equals()
being needed not == have been found and corrected. Applet does not yet connect
to java server there are still some issues with using the cdplayer machine instead
of the laptop. We need to get that fixed ASAP. However java server is ready
to accept applet style inputs once the connect issue is resolved. This is due
to server activating robot when user 0 logs on and applet allowing any user
to control robot at any time no one else is. Likely the server will be changed
so that any connection # can activate robot.
See you tomorrow.
Attached is my power point pres for Thursday please go over and make suggestions.
I got the java server working it boiled down to
if (str == "m")
today things were going fairly well I even began a very crude find algorithm last weekend.
See you thursday
String Tokenizer was adapted into the java server.
The expected inputs of the java server were changed to match the expected inputs from the java applet The FIND class was added but currently does nothing. Overall things are slightly behind schedule since I have been unable to do any testing on the robot due to the mechanical difficulties of the fan. Which appears to still be causing problems.
Well after the fears of virus spreading from our web server have subsided progress
marches ever onward. still working on unlocking the of the brakes. When that
is complete we will be ready to implement java server fulltime.
Progress continues also on implementing stringtokenizer. The find class has been created but right now does nothing. It will be moving much swifter now.
I noticed that after the problem occurred and I then shutdown the server from
user number 1, the server attempts to close all connections before shutting
down, (killall method is ServicClient class) it throws and exception when trying
to close connection #0 which is really no longer connected at all. I will work
on it and we shall discuss Thursday.
Not a problem at all...i had a little fun in lab yesterday and took the bot
for a spin in the hallway...even went and said hello to junior lab, with my
server running as a telnet session. My server is up and working properly now.
I added the feature that one could type "quit" to disconnect only
themselves. That seemed to correct the problem I was seeing last week (presuming
someone actually types quit which will be automated in the new applet). The
only thing holding me up right now is that when user 0 disconnects I call shutdown
which locks the brakes, when I start up the robot again (user reconnects) the
brakes are still on. I had to manually press the white button to release them.
I hope sometime next week to start the finding algorithm, isn't there a mapping
software that comes with the robot?
The progress of the BOTDOCK project is as follows
The java server is still under construction but has come a long way. Probably around 90-95% complete. During lab on Thursday January, 31 2002 I shall attempt to but the server on pioneer1 and use it as the primary and only robot server. The find algorithm is not yet begun, it will begin when I successfully implement the java server, I did look over a little bit of research on the subject including the twice copied paper on open source software for localization of robots The new user interface will begin after the find algorithm is complete. Porting to handheld device will begin after new web interface. All of the items for this project are for the moment on track.
wrote these for Pioneer1 The first one filemanip.java is just a test to see
what worked and did not
it runs as is. The second one is a part of the
java server I am building for pioneer1 it is simpler but works with my server
Thought they may be useful for examples or anything else