|
Just when I thought I had the colour detection figured out, I find out that I don't. At first I thought the calibration was permanently messed up because no matter what I couldn't see where the problem was. Then when I made it smaller (only detecting three colours) I realized that it was consistently out of order. For example, if I have it set to only differentiate between RGB, and I set the outputs to RGB, it would instead recognize it in the order of GBR. I realized all it had to do was the order in which the [coll], and later on a [gate] was being updated. Before the coll was first, then the gate. But it should be the gate, then the coll. It was a simple fix of adding a [t i i] to correct the order in which events were happening.
I really hope this is the last time the colour detection is thrown off. Now I just need to figure out what to play!
0 Comments
Today I plugged in the the GLOBE and it wasn't recognizing any of the colours properly. I tilted the ball slightly and it is doing a lot better, but I shouldn't have to worry about getting the ball at the exact angle needed to get it to work. Now I have to figure out a way to calibrate the reference colours for the colour detection, or else it just won't work consistently.
I figured out that the insert message does work for updating the the [coll]. The only thing is the coll then grows to be very big and long because the former messages does not go away, they just get pushed farther down in the coll while the updated messages take their place in the list. I don't know if there is a maximum size that a coll can be, so every once in a while I should open the calibration text file and delete the extra lines. Or have it always open to a default with only 7 list items before calibrating. I liked Timo's strange actuator patch and re-mapped the FSRs to that instead. It sounds better with the additive synth for the IR sensor, than the [bowedbar~] object did. It hit me that I was overcomplicating things the way I was differentiating between RGB. If I am just to select whichever one is a higher value, then if I'm only using RGB, then it will tell me which it's sensing. I can't believe I didn't think of that earlier. Maybe because I was already trying to figure out how to get at least one more colour detected, my mind bypassed the obvious and went straight to the more difficult, convoluted method. https://cycling74.com/forums/help-urgent-compare-3-values-and-export-unique-message This is fine for just detecting RGB, but it gets more complicated when trying to recognize other colours, like orange, yellow, and purple. I went back to the previous example posted in the forums that does a comparison between the colour on the USB camera to colours stored in a coll. https://cycling74.com/forums/max-msp-colour-detection-help-needed It was when looking at this example that I realized that either the way my data is scaled, or the way the sensor works, colours with red-ish undertones are not as accurately represented in the jitter matrix and [pwindow] than the greens and the blues. This has been going on the whole time, not just with this example. A way around this is to record the values I am getting for all of the actual colours, whatever they may be, then store it in the coll to compare it (rather than using the true colours coming directly from the sensor). For example, when my bright red is detected, it comes off as a purpley/magenta colour in the [pwindow]. I would then take those values, and in the coll label it as red, even though those values are technically not red. I tried it and with much experimentation I am able to get, red, orange, yellow, green, blue, purple, and off. Although, once I move out from my basement suite in Calgary, "off" will look different because at the moment it has the stored value of my desk colour. I should probably figure out how to make a bottom so that "off" stays consistent. This coll method was also difficult to do because the more colours I added to the coll, the more likely I got false readings. Also my paint chips have different shades to them, and it was difficult to figure out which was the best shade to sample in order to get the least amount of false readings, and to have the most amount of correct readings for each shade per colour. I found that the lightest shade of each colour, except the orange, worked the best. For the orange, the second lightest shade was the best to sample. I manually sampled the colours, meaning I connected a message box, put the colour under, disconnected the message box, then added the RGB values to the correlated listing in the coll. Down the road I would like to figure out how to sample colours seamlessly on the fly. But in the coll helpfile I can see that you can add to it with the "insert" message, but it does not replace the existing list; it only adds another line. This may be easier done with just message boxes for each item reference for the sake of flexibility. Now to add the whole rainbow to my demo patch!  I started up the instrument today to find that everything I figured out last night with the colour recognition is not working properly. I'll redo it, but if it goes wonky tomorrow, I'll forget about it and try something else with it. I realized that if the ball shifts in it's stand, then it messes up the colour sensor readings.
I also found something similar here: https://cycling74.com/forums/max-msp-colour-detection-help-needed I'll first figure out my FSR mapping and then maybe come back to this after. I've mapped the FSRs to the chromatic C scale. I'm using CNMAT's [bowedbar~] object to make them sound kind of like a marimba-like instrument. At first I really liked the timbre of it, but now I'm feeling like it doesn't quite work with everything else. Maybe I should play around with it to make it sound different. Or figure out another simople synth. I added electrical tape to the two FSRs that bleed into each other so that I can tell by their texture which ones they are. Working away at getting a demo going. So far, I have the IR sensor mapped to an additive synth. I have the amplitude of the partials randomly changing to give it more texture. It was tricky figuring out how to make it so changing the amplitude of each of the partials didn't make pops. I'm working at getting the colour sensor to control the speed of which the partial's amplitudes change. I was trying for the longest time to get the colour sensor mapped onto a [swatch] object, but the saturation kept going down and I couldn't figure out how to make it steady. I instead mapped it to a [jit.matrix] and doubled the brightness with a [jit.brcosa]. When I place any colour in front of the sensor, it shows in the pwindow. But the tricky part is to have useable data to represent each colour in order to use specific colours to trigger other things. I ended up doing a comparison of all three colours in order to tell if the colour is either red, green, blue, or yellow. It's a bit clunky, but for my purposes (for now) it works. Purple appears too similar to blue and orange appears too similar to yellow to be recognized in this manner. Alternatively, I could have used some sort of machine learning to do this, and perhaps be able to differentiate between the whole rainbow (or perhaps not). I should keep this in mind for the future.  I started to organize my Arduino to Max patch a bit. The RGB values I actually changed the background colours of the float boxes to RGB. I changed the accelerometer data float boxes to light blue. And I changed the IR data box to purple. The order that the FSRs data are printed in are not the order that they are laid out on the ball. This is because I went with whatever was physically easiest/closest to hookup, and that's not always the same order as on the multiplexer (this happened with TRAVIS I and II too). I first organized the layout of the FSRs data in the patch to match the physical layout. This is how it matches up: Right Side: FSR1 = S1 FSR2 = S8 FSR3 = S2 FSR4 = S7 FSR5 = S3 FSR6 = S6 FSR7 =S4 FSR8 = S5 S13 is always a little high when at rest (~450-600). There is an issue with four of the FSRs, mostly on the Left side, in that they bleed into each other.
I thought of taking out the circuitboard and going over the connections again. However, I am sure that all the connections were fine when I tested with a multimeter. Also, I risk making the situation worse and it was very difficult to get all of the sensors plugged in in the first place. I detached the FSRs on the left side that were bleeding into each other and re-arranged them so that the three on the left side are all close to each other. When I moved S16, when I re-attached it, it now sits higher than it was previously when it is at rest. I pulled it off, then put it back on again and then it was back to the way it was. Since that fixed it, I tried the same thing with S13. When I pulled it off, the data went down to where it should be. I think this is because part of the tail of the FSR was bending in a way that it shouldn't and pulling it off the ball straightens it. However, every time I tried re-attaching it, once I press on it again, it would go back to resting high. I'm just going to have to deal with it in Max. The new arrangement is as follows: FSR9 = S13 FSR10 = S11 FSR11 = S14 FSR12 = S15 FSR13 = S16 FSR14 = S12 FSR15 = S9 FSR16 = S10  I finally figured out how to solve the problem of Max messing up the sensor data stream through serial! What it was, was one of the [zl group] objects needed a larger number as its argument. Now I just need to come up with a demo and make it completely wireless! Since I am no longer allowed to invite people to play my instrument, and I am going to have to do my performance online, I may change it so I can collect audience feedback from the online viewers. I added sugru to the stand so it is easier to slip paint chips underneath the colour sensor.  I tried pulling apart the FSR wires a little more, but it was difficult. Then I attached the FSRs for good to the ball. If I need to change their placement I can, but I would have to use my double sided tape to re-attach them. I ordered more sugru in order to lift the stand up a bit. Now I really need to fix the maxpatch in order for the lists to not be split up in half.
Every time I think I'm just one more step away from finishing the physical side, something else comes up. I hot glued the LED strip to the inside of the ball. It's actually a lot harder than it look to put the ball together with the LEDs attached without accidentally pulling apart the connection for the LEDs in one spot. I should have made that spot's wires much longer. I worked around it by adding an extension to that one joint. I didn't want to ruin the hot glue and pull the LEDs off the ball to lengthen the wires.
I used scotch tape to temporarily tape the FSRs into place. When I tried to plug everything in, I realized a few things. The wires are much messier in real life than what I imagined. It was much more difficult to plug in everything and I should have gotten a hamster ball that opens on both sides. I should have oriented the USB connector towards the opening. I should have added a battery switch to the circuitboard.
So I unplugged everything and took out the circuitboard and added a switch for both batteries. It would still be difficult to switch the ESP9266 from being plugged into one battery to the other though. I plugged in the USB cable and I think once I go wireless, I'm just going to stuff the cable into the bottom of the ball. Next I'll see if there really isn't anything else I can do to clean up these wires, then I'm going to attach the FSRs for real. Then go back to working on making all the other sensors wireless. I will also have to test if the paint chips can slip under the 3D printed stand easily. Campus has now come much closer to a complete lockdown due to covid-19... yay... so I'm definitely not going to 3D print ever again until I can get my own printer. :( If the stand is too tall, I'mm have to sand it lots, and if it's too short I'll add something like sugru to it to lift it up.
I came to the realization that I shouldn't have soldered the LED strips completely together and should have added connectors at each point. Oops. So I did that and found out that there was a connection/solder problem at the ground header on the circuit board. There was also one connection near the end of the strip where the power wasn't that good, so I fixed that too (I hope). I also discovered that when I turn off the LED on the colour sensor, the readings from it are not good enough to activate the LED strip, so it effectively turns it off too. Now I just need to take out the hot glue gun and attach everything!
|
Welcome!If you are looking for a summary for my Masters thesis, it is here. Archives
October 2023
Categories
|
RSS Feed
