Hi Roger, Your revised API looks good. I see no reason to keep it consistent with the RCX version. gotoPoint was used because goto was a reserved Java word, but goTo() looks like a good solution. setPosition() might come in handy if Claude Bauman figures out a triangulation method for localization. He's working on that apparently.
There's a few ways we can make it more friendly which I was going to add whenever you are done with the code. I'll run them by: - adding some methods that don't require a boolean value and default by not returning until done (I think that would be the most common usage). - the travel() method could have helper methods of forward(tacho) and backward(tacho), since it seems like forward() and backward() should have tacho compliments. - Using a default speed for the motors (zero really screwed me up initially) then when the Navigator/SteeringControl gets two motors it looks at the speed of one and grabs that. - Your API docs said something about how turn() doesn't end with the same speed after it is called? Does that mean the speech changes during the turn or does it actually keep a slower speed after the method has finished? (more below) ----- Original Message ----- From: "Roger Glassey" <[EMAIL PROTECTED]> > > More comments & questions for you: > 1.. Navigator interface ? should it include the turn() methods? or > would a simpler navigator (TachoNavigator) that only rotates and > drives straight be useful enough to be a a separate class? If you think the turn() methods can apply to all types of Navigator, especially CompassNavigator, then I think it should be part of the interface. With your new methods we can probably include turn() for vehicles that use only analog steering, correct? That would expand the usage of these classes even more (though of course the rotateTo() methods woudln't work with analogue steering). Maybe after this we could use just your turn method code and apply it to an AnalogueSteeringNavigator(). > 2. Compass navigator: how should the compass data be used in > connection with the tacho count data to produce a better estimate of > the robot heading? (a) continuously update heading as the robot moves? > or (b) recalculate the heading after the robot stops? If (b) then > I think the only modification of CircleNavigator is in the > updatePosition method. In which case, CompassNavigator might be a > subclass. of circleNavigator. We probably only want to use the compass for the methods that turn the robot. I'm not sure how helpful the compass would be to keep the robot on a straight path, since metallic objects in the area will interfere (wobbly line). The advantage of using the compass to navigate is that if your robot gets bumped the compass would straighten it out, so it would be more robust, especially on rough terrain. Maybe this could be an option in the constructor or a special setCompassMode() setting. I haven't been able to tell how quickly the Mindsensors.com compass can produce a reading, but if it's almost instantaneous then we could probably read directly from it, even if your code needed to use it while in motion. Maybe it could start to slow down as it starts to approach the desired angle. > 3. Speed test ? no I have not checked the speed, but it is probably > pretty good, since the control loop compares the actual tacho count > with speed * elapsed time and keeps this error very small. > > 4. Ramp up control. I think I know how smooth the acceleration to > high power levels to avoid skidding wheels. Work in progress. Just like traction control on cars. :) - B ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Lejos-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lejos-discussion
