CompassPilot and Legacy classes in navigation package

A place to discus the development of leJOS for the EV3. Please do not use this forum to post questions about how to use leJOS or to report problems etc.

CompassPilot and Legacy classes in navigation package

Postby bbagnall » Tue Mar 11, 2014 8:52 pm

Anyone have any problems with removing LegacyNavigator, LegacyPilot, and CompassPilot from lejos.robotics.navigation?

I will replace CompassPilot with CompassPoseProvider. The plan is to extend OdometryPoseProvider and override the getPose() method to get directional data from the compass instead of odometry.

If we ever make a PoseProvider that can synthesize data from multiple sensors, including Compass, then this class will be redundant and we can get rid of it.
User avatar
bbagnall
Site Admin
 
Posts: 392
Joined: Fri Aug 04, 2006 4:03 pm

Re: CompassPilot and Legacy classes in navigation package

Postby gloomyandy » Tue Mar 11, 2014 9:06 pm

Hi Brian,
you might want to talk to Aswin about this. There are a number of compass/gyro/accelerometer devices available now and they can be combined to provide a poor mans inertial platform. I know Aswin has a done a fair bit of work in this area. It would be nice to have this sort of device included. Perhaps it could degenerate to a compass only case if that is the only sensor available?

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3881
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: CompassPilot and Legacy classes in navigation package

Postby Aswin » Wed Mar 12, 2014 12:18 am

Hi Brian,

I don't know if this is better discussed on the developer list or here. But anyway.

The problem with the compassPilot is that that it tries to combine two competing designs. The first is that the pilot maintains location and heading by itself, and is implemented in the differential pilot that the compassPilot extends. The other design is that heading is maintained by a compass in this pilot. These two designs cannot be combined. So the compass pilot cannot extend the differentialPilot.

In my opinion it is best to always separate localization from a pilot, not to maintain the pose within the Pilot. These are different tasks. A pilot without odometry built in might still needs to have access to position and heading. This should be done via a "PoseData" interface that gives access to just position and heading.
You would also need classes that maintains pose, how these classes work does not matter to the pilot. But one of these classes uses odometry, the other a compass, or integrated gyro, or GPS, or whatever combination.
These classes should implement this simple interface interface. Now it does not matter to the pilot where the poseData is coming from. Only one differentialpilot is needed and the compassPilot becomes obsolete.

some technical remarks:
- I have quite a lot of experience with such a design for my holonomic robots. I never experienced performance problems.
- I suspect this design also reduces the need for calls to listeners in the motor, pilot, navigator setup. As far as I remember a number of these calls are made to trigger an update of heading and location. I am not sure however.
My NXT blog: http://nxttime.wordpress.com/
Aswin
leJOS Team Member
 
Posts: 197
Joined: Tue Apr 26, 2011 9:18 pm
Location: Netherlands

Re: CompassPilot and Legacy classes in navigation package

Postby bbagnall » Wed Mar 12, 2014 3:26 pm

Hi Aswin,

Ok, it sounds like we can get rid of CompassPilot. I will leave CompassPoseProvider until the time when we can use compass data with the navigator classes through your new API.

Do you have working code to demonstrate your API integrating readings from different sensors to come up with pose data?

On another note, we were previously talking about replacing the current OmniPilot with yours, which I believe allowed for different angles of wheels. And perhaps 4 wheels too, though I'm not sure about that. Now would be a good time to do the replacement at the beginning of the EV3 cycle.

Brian
User avatar
bbagnall
Site Admin
 
Posts: 392
Joined: Fri Aug 04, 2006 4:03 pm

Re: CompassPilot and Legacy classes in navigation package

Postby roger » Wed Mar 12, 2014 6:36 pm

As I read the compass pilot code, it does not keep track of x or y. It does know of the desired heading, attempts to keep the pilot on a straight path along that heading. So please do not delete it. I agree that maintaining the pose is not the responsibility of the Pilot, but using a direction finder to travel in a straight line is. In fact, only a Pilot should be issuing commands to adjust motor speed.
It is a good idea to delete the legacy classes.
Roger
roger
Moderator
 
Posts: 357
Joined: Fri Jun 01, 2007 4:31 am
Location: Berkeley, CA

Re: CompassPilot and Legacy classes in navigation package

Postby bbagnall » Thu Mar 13, 2014 2:14 pm

I agree with Roger, there is some functionality in the CompassPilot that is not duplicated by the temporary CompassPoseProvider. I've reinstated the CompassPilot from Git.

Long term, we will want to add the ability of Navigator or perhaps pilots to course-correct as they travel using whatever real-time odometry they have available. Currently our model is to point in the right direction, close your eyes and keep driving until the distance has been covered (with the exception of CompassPilot). It might be easier to implement course-correcting travel at the Navigator level if we switch to continuous movement (the navigator could break up a long trip from x1y1 to x2y2 into smaller segments that would look like one continuous move). I recall we had quite a few discussions about the possibility of continuous movement, which Lawrie favored, but in the end we decided we needed to make baby steps first with all the changes we were doing with the navigation framework at the time.

Also, we'll need to allow the API to distinguish which pose providing techniques allow for continuous pose readings, and which require the robot to stop. For example, MCL or laser beacons require a stationary robot and several seconds to assess pose data (including heading). Gyro, compass, GPS, tachometers on the other hand can take multiple readings on the run. I can see a nice demo where we ask the robot to drive to a set of coordinates, but then as its travelling we pick it up, rotate it and put it down a few feet over, but the gyros pick up this movement and course correct to reach the coordinates anyway. This would be the most robust our navigation has ever been.

Adding this type of framework to navigation will also depend on the changes that Aswin is making with the sensor framework.
User avatar
bbagnall
Site Admin
 
Posts: 392
Joined: Fri Aug 04, 2006 4:03 pm

Re: CompassPilot and Legacy classes in navigation package

Postby Aswin » Mon Mar 17, 2014 10:20 pm

bbagnall wrote:Do you have working code to demonstrate your API integrating readings from different sensors to come up with pose data?

I do not have such an API.

bbagnall wrote:On another note, we were previously talking about replacing the current OmniPilot with yours, which I believe allowed for different angles of wheels. And perhaps 4 wheels too, though I'm not sure about that. Now would be a good time to do the replacement at the beginning of the EV3 cycle.


The problem is that this pilot cannot be integrated in the navigation framework. The major issue is that it cannot be a MoveProvider. This pilot combines simple moves to make more complex maneuvres. The end result cannot be described as arcs, rotates, travels or stops. For example, the pilot allows the robot to rotate while travelling or making an arc.
As this pilot cannot be a MoveProvider it can also not be a MoveController although it can make al the movements that the <Arc><Rotate>MoveControllers can make. It therefor can also not be used with a OdometryPoseProvider.
Could the MoveProvider interface be seperated from the MoveController interface? Because then I think the pilot can be integrated in the navigation framework.

Aswin
My NXT blog: http://nxttime.wordpress.com/
Aswin
leJOS Team Member
 
Posts: 197
Joined: Tue Apr 26, 2011 9:18 pm
Location: Netherlands

Re: CompassPilot and Legacy classes in navigation package

Postby bbagnall » Tue Mar 18, 2014 2:10 pm

Aswin wrote:The problem is that this pilot cannot be integrated in the navigation framework. The major issue is that it cannot be a MoveProvider. This pilot combines simple moves to make more complex maneuvres. The end result cannot be described as arcs, rotates, travels or stops. For example, the pilot allows the robot to rotate while travelling or making an arc.
As this pilot cannot be a MoveProvider it can also not be a MoveController although it can make all the movements that the <Arc><Rotate>MoveControllers can make. It therefor can also not be used with a OdometryPoseProvider.

Is it possible to implement a subset of a holonomic robot's menu of moves using the MoveProvider and MoveController? You can still leave in the specialized moves like rotating while making an arc, but they would only be accessible outside of the navigation framework. I think this might be how the current OmniPilot is able to implement these interfaces.

Also, it might be worth pondering if there is a way to incorporate all 6 degrees of freedom in the navigation framework. When we were designing it we only had experience with differential type robots. Since then we've gained more experience with omniwheels, steering vehicles, and segway (which is a special type of differential robot). We have a ballbot, but haven't tried making a pilot for it yet because the movement algorithms and ability to continue facing forward aren't really physically good enough yet, but it would be nice to know it could accept a ballbot.
Aswin wrote:Could the MoveProvider interface be separated from the MoveController interface? Because then I think the pilot can be integrated in the navigation framework.

I'm not sure what the ramifications would be for MoveController no longer extending MoveProvider. Does the API break when it is separated?

Also, I can't recall but does your version allow for a robot with 4 omni-wheels? It's not necessary as I think 3 wheels has many advantages, but I'm curious.
User avatar
bbagnall
Site Admin
 
Posts: 392
Joined: Fri Aug 04, 2006 4:03 pm


Return to leJOS EV3 Development

Who is online

Users browsing this forum: No registered users and 1 guest

more stuff