Soundsensor

Soundsensor

Below is a very brief test of the NXT soundsensor in the new sound-framework for EV3.

During my test I was quietly humming, which is seen as the small spikes leading up to the big spike, which was when I clapped about 10 cm in front of the sensor. 

DB mode

I tried to continue my humming at the same level, but in retrospect I did move a bit closer to the sensor, and my volume might have increased somewhat. The clap was controlled to somewhat the same loudness.

DBA mode

Not much to say about the results. They are somewhat the same as expected, though the values makes less then perfect sense (what is 0.2 in relation to DB? - what is actually returned is the soundvalue in relating to the maximum possible recording soundlevel of the sensor).

Compass Sensor

EV3 and HiTechnic Compass

Today I'll test if the HiTechnic Compass works as intended with the new EV3. My expectations are that the calibrations will be difficulat (as always), but that the rest should work.

Test setup

First off I'll place the compass sensor about 10 cm above the brick (which is then even further away from the motors). This is to limit the amount of electromagnetic noise registered from these actuators and circuit board. The configuration can be seen her:

Distance of compass from the rest of the robot

I've found, in previous tests with the NXT, that the proximity of actuators and/or the brick itself has a significant impact on the readings of the compass. 10 cm should be quite enough to limit the interference to a negligible amount.

Results

I had to bring the setup out of my appratment, as the walls seem to shield me from the earths magnetic field (hmm...), but once I found an environment where the compass had a chance of working, everything turned out great. Below is a video of my test:

Since I got the compass working at least to the same degree that I got it working for the NXT, I'd say this concludes my tests: EV3 supports this compass to the same degree that the NXT did.
As for the video. The first part is a calibration of the compass. The second part is my attempt to film the changing degrees - I see now that the video is of a too poor quality to show this, but I can assure you that the degrees changed according to what I expected while I turned on the spot.

Files

CompassTest.java

Gyrosensors

HiTech vs. EV3 Gyrosensor

In this post I will examine how the "old" HiTech Gyrosensor compares to the EV3 Gyrosensor . Seeing as the HiTech Gyrosensor detacts degrees/s and the EV3-sensor allegedly returns some sort of accumulation of degrees (used to make 90 degree turns, according to the LEGO tutorial), I'm unsure how exactly to compare the two. During my examination of how the hardware is used by the people behind leJOS, I'll hopefuly get a good idea of how to proceed.

Finding the old sensor in the new framework

For me this turned out to be a bit of a hunt. As it turns out all the NXT compatible sensors are organized in software packages based upon which producer manufactured them. I spent some time trying to make the GyroSensor class work until I found HiTechnicGyro. Source-code is linked below.

leJOS modes - how a sensor with multiple functions is treated

The EV3 sensor is able to give degree/s OR accumulated degrees. In the new framework this is reflected in each sensor having multiple sensorModes. For the EV3GyroSensor the available modes are:

1. Rates (degrees/s)
2. Angles (accumulated degrees)

After choosing a given mode for a sensor, a sampleprovider is given. This sampleprovider is then able to 'fetch' the data.

It should be noted, that this sampleProvider framework is pervasive for all sensors AND that it is possible (but unpractical) to get all possible sampleProviders from a given sensor, at any given time (for the ev3Gyro: both Rates and Angles). This adds the "hidden" cost of changing the sensors readmode between fetching data from the providers. I tested with alternating between Rates and Angles and found it gave an added latency of about 400ms.

Having experimented with how to misuse the framework, I moved on to actually trying to solve my experiment.

Experiment

First I want to compare how the to sensors performed in the same 'mode'. Below is a video which illustrates how I move the two sensors in relation to each other (ei. how I've built the device for testing). It is NOT, however, a video of my actual test-data. I only rotate the two sensors on the axis they're meant to register for the actual test.

The above shows, from all possible angles, how the setup is constructed. The below data is then collected through measured movements.

EV3 in rates mode (degrees/s)

First 90 degrees counter-clockwise, then 90 degrees counter-clockwise, then 180 degrees clockwise, then 90 degrees clockwise and lastly, 90 degrees counter-clockwise.

EV3 in Angles mode (accumulated degrees)

I see a rising degree of inaccuracy in the Angles mode, which isn't too surprising considering I'm never 'resetting' the accumulation. The first 180 degrees where more or less exactly they way I actually moved the sensor, though (fairly slowly).

The reason I didn't include videos of the above experiments was, quite simply, that I needed both hands to control the gadget because of the tangling wires.

Experiments with breaking the framework

Below is a graph of how badly the EV3 Sensor seems to perform in relation to the HiTechnic Gyro, when both modes interchange when to fetch from the hardware:

EV3 in BOTH Rates and Angles mode

It's fairly clear that this messes up the readings a lot, when compared to how equal the graph is for only rates mode.

Files

DataLogger.java

GyroTest.java

UltraSonic

Comparison of NXT and EV3 UltraSonic Sensors

Today I'll examine these two sensors to see if there is any difference. I suspect that they will perform the same, but my overall goal is to examine alle aspects of all sensors of the EV3. Since I've worked with the NXT Sensors before, I'm using them as a benchmark for how well the newer EV3 sensors perform.

Test inspiration

The next couple of blogposts will be related to this other blog I helped create. The ultrasonic sensors where tested duing week3 of the above experimentations. When I refer to weeknumbers hereafter, I'm referencing to this afformentioned blog.

Week3 was a week dedicated to understanding how ultrasonic sensors work. My goal with the below experiment is not to recreate the expeiment exactly as was, but rather to test if the experiment is feasible with the new EV3 using leJOS. While I'm doing this, I'm sure some sort of picture of how well the new hardware performs will emerge.

The experiment

My test-setup is as depicted below:

Setup for the distance test

The plastic top of the LEGO-box was selected, as we found (in our privious tests), that measuring the distance to some non-vertical thin plastic object posed a significant challenge to the NXT ultrasonic sensor.

Ultrasonic Distance Measurements
Actual distance*	NXT	EV3
45	48	0,475
80	87	0,834
97	108	1,115
110	inf	1,206
120	inf	1,315
137	inf	1,499
>137	inf	inf

* based upon eyemeasure of where the sensor is relative to the measuring tape

I tried my best to make sure that all measurements where at exactly the same distance and I feel confident that they where all done within 1cm of actual distance (to the bottom of the angled slope of the plastic).

First off I suspected that the problem with the big difference of accuracy was because my NXT sensor was damaged/used, so I tried another one, with the same results. This leads me to conclude, that the new EV3 Ultrasonic sensor is actually quite a bit better at detecting difficult objects.

Second test

I did implement the WallFollower mentioned on the other blog, but the result was just as bad as in our first attempt (I used the exact same code, corrected for the new sensor-framework). These results are not included, but I wanted to confirm that it is indeed possible to make a wallfollower (my implementation was kind of deranged, but it kind of followed a wall).

Lightsensors

Overview

Today I'm going to experiment with the old and new light-sensors on my EV3 brick. I'll do, roughly, the same exercise as I've previously done in this post on another blog, to see if I can recreate that result in the leJOS-EV3 framework.

Initial test

First off I'll simply try to read the light-intensity values from an array of differently colored LEGO-blocks. I've decided to slide the blocks along below the sensor, so I can leave it fixed and untouched between color-switches.

Without Floodlight
	NXT-Light	NXT-Color	EV3-Color	Old NXT-Light Readings
White	0,4422	,8436	0,17	31
Yellow	0,4237	,8436	0,15	29
Red	0,3973	...	0,11	30
Turquoise	0,3426	Sensor borken?	0,065	22
Green	0,3143		0,04	23
Purple	0,3758		0,09	29
Blue	0,3495		0,07	25
Light-grey	0,3534		0,075	25
Dark-grey	0,3074		0,035	23
Black	0,2547		0,02	18
Diff from White to Black	1:1,74	??	1:8,5	1:1,72

Different values, but the same deviation from white to black for the two NXT-Light readings. The interesting part is, that the deviation for ambient-light of the EV3-Color sensor, is actually quite a bit better. I'm a bit put off but the lack of accuracy on the sensor-reportings, though.

Now with the floodlight (red LED-light) enabled:

Floodlight (red)
	NXT-Light	EV3-Color	Old NXT-Light readings
White	0,6376	0,665	60
Yellow	0,6259	0,59	60
Red	0,6122	0,41	54
Turquoise	0,4462	0,075	33
Green	0,4911	0,05	37
Purple	0,5574	0,21	47
Blue	0,5057	0,05	33
Light-grey	0,5595	0,22	48
Dark-grey	0,5116	0,11	42
Black	0,4813	0,04	35
Diff from White to Black	1:1,32	1:16,625	1:1,71

Here, the EV3-Color sensor actually performs much better at detecting the difference of White and Black. Most of the tested colors are between 0.11 and 0.4, though. This leaves most of the colors in with a fairly small deviation of 1:2,75 (which is still a lot better then the old sensor).

Suspected difference: Old lightsensor is approximately 4 mm closer to the surface I'm reading, at a distance of 5 mm, whereas the new sensor is at 9 mm distance.

EV3 Color Sensor

NXT Light Sensor

Now for a test where I'll ensure that the distance from the sensor-head is equal (5mm)...

EV3-Color
	Without Floodlight	Floodlight (red)
White	0,11	1,05
Yellow	0,07	0,97
Red	0,05	0,66
Turquoise	0,04	0,13
Green	0,02	0,095
Purple	0,05	0,34
Blue	0,04	0,14
Light-grey	0,04	0,41
Dark-grey	0,02	0,21
Black	0,01	0,19
Diff from White to Black	1:11	1:5,53

Hmm, even worse... Now the scale is broken for the White value, which can only be defined as BAD. I checked up on the implementation-notes in-code: Values should be in the range [0.0;1.0], so I suspect these readings may be misleading :\