Wall squaring

[humbug99]

Backing into the wall with the default single following body doesn't behave as I would have expected it to: the back of the robot rides up the wall (or, it bounces up and down if the wall is high enough and the robot keeps backing up for long enough). This means that the robot doesn't reliably come off the wall anywhere near straight.

Maybe this is due to the gravity setting? I tried turning up the body mass to 3000, but now it seems that the robot is slipping more than I expect. I could turn up the wheel friction, or change the gravity setting, but I guess that changing either of these might result in other consequences.

Any thoughts on what parameters to tweak to allow wall squaring to work reasonably?

[QuirkyCort]

This one is really tricky. I've tried tweaking the parameters to get wall squaring to work, but every parameter will affect multiple behaviours, and I haven't been able to find the right balance between them yet; not sure if such a sweet spot even exists. A big part of the problem is the limitations of the physic engine and the need to maintain an acceptable performance for users of slow machines (...which includes myself; my laptop is a 1.1Ghz Celeron).

If you want to give tuning the parameters a shot, here are what you can try...

Gravity: This is currently set to 1/10th of actual gravity. Increasing this will help, but will increase instability in the physics engine behaviour.

Physics steps: Increasing the number of steps per frame will improve stability and compensate for an increased gravity, but it'll reduce performance and may cause inaccuracy if the frame rate drops too low (...as physics steps are tied to wall clock time).

Body mass: This will help pull the body down and prevent it riding up the wall, but it also increases inertia, making the robot slip when turning and accelerating.

Reduce wheel friction: This will let the tires slip more easily when the robot is up against the wall, but will increase slip when accelerating and turning.

Reduce wheel downward force: This is an artificial force that's added to increase tire grip. Reducing it will have the same effect as reducing friction.

Increase wall and body friction: This will make it harder for the robot to ride up the wall, but will also make it harder for the robot to glide along a wall.

Robot design: For the default robot, the contact point with the wall is relatively high up; just a little below the wheel axis. Lowering this will reduce the tendency to ride up the wall, but make it harder for the robot to drive over obstacles. This change alone also may not be adequate (...may work better with increasing physics step).

Reduce wheel torque: This will let the motor stall when the robot is up against a wall. A low torque will make the robot respond slower when line following, and can cause it to lose the line.

I'm inclined to add support for the duty cycle setting (...unregulated motor in EV3G terminology), which is similar to the last parameter (...wheel torque), but make it the user's responsibility to use it when they want to wall square. This will allow all the parameters to stay the same, but it will still result in poor behaviour if you tried to wall square using a regulated motor block.

[humbug99]

What do you think about increasing the body friction and then adding narrow side rails along the body with low friction?

[QuirkyCort]

Can't. The side rails are part of the main body and have the same friction value. There are no easy ways to add a side rail as a different body.

[humbug99]

Is that because of the parenting of babylon objects? If so, how about adding an object next to the side that is connected by a joint rather than by parent/child? For example, add small vertical cylinders to the side walls such that they are connected to the body by hinge joints? (Or, maybe a LockJoint with a side rail box, but Ammo apparently doesn't have the LockJoint...)

[QuirkyCort]

When parts are parented, they are treated as a single compound object. So only one friction value.

Joints will work, but Ammo (...at least in the Babylon plugin) doesn't have a lock join. Joints also bring their own set of issues; they are not rigidly fixed (...even when they are supposed to be) and tends to be "bouncy" (...try ramming an arm into a wall to see what I mean). They also increase the physics workload.

Your side rollers idea may work, allowing us to set a higher body friction, but while a higher body friction may make it harder for the robot to ride up the wall when wall squaring, it'll also make it harder for robot to slide back down when it does go up. You can try testing the higher friction and see if that helps.

[humbug99]

My team wants to wall square, so I'm looking at this again.

I found that dropping the center of gravity of the robot (making the main body lower and shorter) and moving the wheels back some seems to help, as long as you go slowly into the wall and you don't back up for too long, I also added a thin box on the back of the robot to lower the contact point.
I think this combination will be adequate for us to practice with.

In case someone else is trying to do this: the mass of child objects is completely ignored. You would think that to move the center of gravity you could add a child object (e.g. Box component) with mass, but in fact this doesn't do anything. To change the center of gravity you have to change the size/placement of the main robot body part.

As an experiment, I tried replacing the standard caster with a new robot component that is a sphere connected to the main body by a BallAndSocket Joint (multi axis rotation). This allows the main body friction to be higher than the caster friction (really, the caster friction doesn't matter anymore because now the caster sphere is rolling rather than sliding.) The nice thing about doing it this way is that it would be possible to use the same component to allow wall following by adding two of these (smaller than the main caster) to each side. (The mass of the caster sphere in this case does change the mass and the center of mass of the robot, so this also allows for more flexibility in terms of the robot physics). So far I don't see much additional benefit doing this vs the changes I described above. I will eventually clean this component up and turn it into a PR, but I'm not going to be in rush to do so (unless someone wants this?)

[QuirkyCort]

The flexibility in adjusting the center of gravity using a separate sphere as a caster is interesting, but it's a very big change to the physics of the robot and will potentially break a lot of existing programs.

Will be happy to accept it as a PR if it's implemented as an optional component that can be added in the robot configurator (...together with an option to omit the built-in caster on the main body).

When trying to improve wall squaring by shifting center of gravity backwards, be careful as this will also increase the moment of inertia when turning.