Qik Easy IR Sensor Documentation for Pybricks

[PewPewPewP]

we have a 360 degree qikeasy ir seeker, how do we use it with the pybircks software, if anyone knows could you give us the code to print the values

[dlech]

It looks like it uses the SPIKE PRIME Color sensor interface. https://www.qikeasy.com/ir-seeker-usage-with-spike-prime/

This will not be compatible with how Pybricks uses color sensors. But that is OK. This is exactly why we have the PUPDevice class. https://docs.pybricks.com/en/stable/iodevices/pupdevice.html

I don't know if we have a good place where we documented which mode number corresponds to which mode. Maybe @BertLindeman or @JorgePe will remember where we dumped that info when we were first reverse-engineering the senors?

[PewPewPewP]

Yep, the it sensors is read as a colour sensor. However I can’t figure out how to make it read raw red or raw “colours” with rgb in Pybricks because that is how direction and strength is shown in mindstorms and spike prime block coding. Is there a way to do that?

[dlech]

It is the probably the TRAW mode (or maybe ADRAW), so you would replace the 0 in read(0) with 5 to read that mode. It should return a tuple of values that should contain the red, green and blue raw values.

[learncodenow2012-beep]

with the color sensor rgb stuff, how do we get the seperate red green and blue values?

[dlech]

That is what I meant when I said that it should return a tuple. The RGB_I mode (5) says it returns 4x values. So you can write it like:

red, green, blue, ambient = device.read(5)

The commas "unpack" the tuple into individual values.

[neiloswin]

Hey, we're using the QikEasy sensor for Robocup junior nationals this year, is there any way that you could run a quick firmware update to allow the sensor to read raw 360 degree direct values towards the ball (or IR transmitter) rather than reading the 1-18 values.

Thanks

[nazeeh111]

The published Spike/Pybricks mapping is sector-valued, not a 0–359° angle. QikEasy’s working-theory page says direction is 0 for no signal and 1–9 for detected sectors; the Spike interface multiplies the value by four. So a 0–36 value is a scaled code for those sectors, not 36 or 360 angle steps. On the Spike/Pybricks path, the first seeker’s direction is exposed as the reflection value and its strength as raw red; the second seeker uses raw blue for direction and raw green for strength, per the usage guide.

QikEasy also documents native I²C registers for the separate strengths from all five receivers. Those measurements could support a calibrated software estimate between sectors (that is an inference; I have not tested an interpolation), but the documented Spike/Pybricks color-sensor interface does not expose those five strengths individually. The Pybricks PUPDevice info/read methods only expose modes reported by the connected device, as described in the Pybricks docs.

A firmware update could expose additional data if QikEasy supports adding such a mode, but I can’t confirm that feasibility from the published docs. If you’re seeing values 1–18, could you share the exact mode and PUPDevice info output? The current QikEasy guide describes 1–9 direction sectors. This is a source-based answer only; I haven’t tested the sensor or an interpolation algorithm. Prepared with Codex assistance.