Measurements have been made, showing that the found ball and man positions were slightly off in every second picture. This is due to the coarseness of the u and v channels. Fixed by adding or subtracting a value for every second scan picture to the found position.

A rather simple DefenseAttack mode has been implemented. It tries to move the man around the ball and shoot. Nothing more, nothing less. It works ok in the simulator but could be a lot smarter.

Also another problem was fixed. We noticed that the motors heated even though they weren’t in use.

When they weren’t in use the MC software set the engine voltages at 128. But tests showed that the zero voltage wasn’t 128 for the motors, in fact, they were all different, but within 128 +- 5. As a result a fix was implemented that turns the power off completely (PWM_OFF) if the motor voltage is within 128+- 15 because the rods won’t move for voltages closer to 128 value anyway.

Now the motors are nice & cool (when they aren’t in use).

The test results are attached 

-,164: 129
-,111: 130
-,07: 131
-,039: 132
0,006:133
0,054:134

20 amps offense
10 apms (II) offense
0,04:134
-0,003:133
-0,041:132

CENTER
0,206:128
0.325:130
0.220:127
0,144:125
0,061:123
0,030:122<—-
0,060:121

DEFENSE
0,065:135
0,45:133
0,39:132
0,29:131
0,21:130
0,05:128
-0,03:127<—-
-0,11:126
-0,19:125

CENTER2
0,27:128
-0,07:123
-0,04:122
-0,05:121

OFFENSE2
0,04:134
-0,001:133<—-
-0,03:132
-0,08:131

GOALIE
0,19:128
0,12:127
0,036:126<—–
-0,06:125
-0,15:123

 

• Logging text to more than one file per frame. I.e. it’s not possible to do both profiling and value logging as we tended to do it before.
• Not having a sleep() in CommunicatorThread when not using the serial port. This is because the loop in that thread otherwise consumes 100% CPU.
• Running other programs on rt14 at the same time, even just the “top” program which shows a list of the running processes.

The project is in VSS (microsoft visual source safe) on our windows pc. From there we can retrieve the files on the same computer and from the macbook. When someone wants to compile it, he copies his source files to rt14 (takes a couple of seconds) and compiles and runs it from there. This way we can both edit the files at the same time and we don’t have to wait for the other guy to have some code that compiles – the code in vss must always work.

This way we also have no trouble merging our projects, vs and vss takes care of most of it. We only have to resolve the conflicts that may arise.

Another thing we found out today was that using ssh tunneling through rt14, we can do remote desktopping on the windows machine. This means that we can work from home as long as we are not using the actual foosball table.

The run showed that the speed of the simulation is a bit hardware dependent. The ball now moves around and comes to a stop a bit faster, this is also a job for tomorrow to fix.
It will be interesting to see wether or not the newly fixed implementations still compile on rt14.

The inclining surfaces near the borders and corners of the table are now simulated quite nicely. For some reason they apply too great a force to the ball still. Maybe due to the rotational inertia of the ball, which we don’t simulate at present?

The rolling friction on the ball seems pretty accurate now.

A bug was corrected in the rod update function, so the rods don’t move instantaneously anymore.

The most important feature missing in the simulator now is collision detection and the corresponding change in ball velocity. I wonder how we’re gonna do that…