End-project. PART XII

---

Date: 19 01 2009
Duration of activity: 5 hours + (2.5 + 2.5 hours of homework)
Group members participating: all group members + (Anders D. and Anders B. of homework)

---

1. The Goal

The goal of this lab session is to improve the stability of the structure as much as possible. Also, as always, to make further adjustments to the code.

2. The Plan

• Make some reconstructions to the LEGO robot.


• Find out a way to work with missing (stolen) parts of the robot.


• Make adjustments to the code.

3. The Results

3.1. Reconstruction

During this lab session it was a challenge to work with the robot we constructed as we found some pieces ``borrowed''. All the time was spent to reconstruct some parts of the robot. Later, we got the parts we needed and a longer cable to connect the motors to the NXT. We made plenty of testing with regards to Z-axis handling.

The part that handles Z-axis movement was redesigned. In this picture it can be seen that the idea that actually moves the part up and down was redesigned to not depend on pressure as we had before, then a pen keeper was changed, and a rather large claw contraption that goes over the carriage was built in order to increase stability.



The overall view of the robot looks like this:



In the following picture one can see the long white cable we tried to use. The interesting thing is that this cable allows to handle motor speed but it does not transmit tacho count readouts, which signifies that the cable isn't fully connected, internally.

3.2. Motor layer

• setSpeed(MotorPort motor, int speed) each motor gets a predetermined mode: x,y gets mode 1, and z gets mode 2. This is due to our build, as there occurs a need to invert Z's movement direction (which could be fixed in both the X- and Y-case by simply redefining origo)


• getTachoCount(MotorPort motor) each motor gets the aforementioned predetermined mode and the tachoCount is correlated in order to match the sign of the axis.

3.3. Calibration layer

• reCalibrate() it seems that is not possible to determine which border we are at if we are pushing safety buttons when starting the calibration.


• findMinAndMax() deals with assigning values to maximum velocity variables: Convert tachos to millimeters, and then divide with the time it took to go from min to max


• getMaxVelocity(MotorPort motor) returns a maximum velocity value for a certain motor.

3.4. Navigation layer

• motorPowerFromFraction (float fraction) condition for returning zero power was corrected.


• motorPowerFromDistance (float[] distance) condition for assigning retrieval for Z-axis to be zero was corrected.

3.5. Gradient interpreter layer

GradientInterpreterStandard

• assureMaintainerRunning() we seemingly get the desired behavior when using setDaemon(true) instead of setting it to false.


• enqueue(GradientGiver newone) checks whether the prior operation in the queue actually ends at the approximately the same point in space where newone starts. If not, aborts the enqueue.


• enqueueLinearMovement(String name, float[] from, float[] to) is an introduced helper method that just enqueues a linear movement between the two points at the maximal speed accessible.

3.6. Bogus handler layer

• findOrigo () was modified a little. After origo is found, it waits until the queue becomes empty (which had caused coordinate keepup problems.)

4. Conclusion

This lab session let us concentrate on making presumably last reconstructions due to increasing accuracy of movement of the sliding part (the one that is placed on the carriage). While running different tests, we noticed that exact carriage placement can be assured by starting at a border, unfortunately, it is impossible to determine at which border (min or max) the carriage is, and the reCalibrate() method will not (and should not) allow this.