|
I thought it would be best to pull the blue LED on the ESP8266 low and have the red LED blink when the board is trying to find the network and solid once it finds it. Well I relized that the red LED is controlled by pin 0 and the blue LED is on pin 2. I am already using those pins for other things. If I had realized this sooner, I should have re-arranged the pins. Oh well. Ya live and learn. Just another thing to add to my speculative improvements.
0 Comments
So this whole time I've been programming the HUZZAH feather with my old windows laptop because not a single ESP8266 board will compile the blink example on my Mac. If I go back to old blog posts, I wrote about the problem in more detail in the past. It requires deep computer surgery and I'm not quite ready to do that on my Mac just yet.
Since I know that I have the code to print the sensor data through UDP and Serial simultaneously, I wanted to use that to add the wireless method to my Arduino to Max GLOBE bpatcher. I would use the matching serial and UDP readings to know which outlet to hookup to for each sensor. I thought it would be easier to do this all on my Windows in case if I needed to re-program the ESP8266. However, I was then having lots of troubles getting Max to print the data through Serial. I was confused because it was printing finr through the serial monitor while also printing through UDP. I finally figured out for whatever reason, my Windows has become unfriendly when it comes to allowing Max to print through Serial. It says that it's connected to port E and sometimes it will print, other times it won't. I have to delete the "e" in the argument of the Serial object and add it in again to get it going (sometimes). I tried plugging into my Mac again, and it was fine. So now I have the problem that I can only program the Arduino code on my Windows, and I can only use Arduino to Max (wired) on my Mac. Once I have everything finalized, this won't be an issue. But for troubleshooting purposes, this is kind of annoying. In the end I added the capabilities to toggle between serial and udp in the bpatcher. I added a little accelerometer mapping. And I started on my dissertation.
I spent a really long time figuring out how to format page numbers, the table of contents, and figures for my dissertation today. There really should just be a template for all grad students...
I was able to figure out how to make the TCS34725 wireless. Now I just need to understand how to also add the LEDs, then combine it with everything else! Edit: I DID IT!!!!! I DID IT! I DID IT!!!!!! And the best part is it also simultaneously prints through serial, so if the battery dies mid performance, I can just plug it in without having to do any crazy re-programming! One thing I noticed, I was carrying it through a dark hallway and the blue LED on the HUZZAH Feather was very bright in the dark. I remember the old ESP8266 + Adafruit LIS3DH arduino code was controlling the on board LEDs. I should look at it again to see if I can pull down the blue LED. Then I'll need to map something onto the accelerometer and start playing some more! Happy April Fools! I didn't see any pranks this year :(
I'm going back to trying to make the whole instrument wireless. I already have the FSRs. I just need my two I2C sensors to be wireless now (Sparkfun LIS3DH and the TCS34725). The IR sensor is connected to the LIS3DH first analog pin. I found a paper where they used the same HUZZAH Feather and an Adafruit LIS3DH, worn by a dancer and sent to Max through UDP: https://www.collin.edu/hr/benefits/cMorgan_sabbaticalSummary_Spr2018b.pdf I played around with the Arduino code that's in their appendix and cut out the bits of code that I don't necessarily need, like controlling the blue and red LEDs on the board. Even though I have the Sparkfun breakout of this particular accelerometer, it still technically works. However, I like how the Sparkfun version prints out its data better than the Adafruit version. I think it has something to do with their libraries. The Sparkfun version prints each axis of data between (1, 0, -1). Whereas the Adafruit prints numbers in the thousands. I am currently having troubles trying to get the way the Sparkfun version to work through UDP. They way it is called to print in serial is not friendly with "message.add" the same way the Adafruit version is. If I have to, I'll use the Adafruit library, but for now I'll keep tinkering away at this. Edit: I figured out how to get the LIS3DH working wirelessly with the Sparkfun library! And it's printing the way it should! It works when I adapted the other LIS3DH code, but I get strange errors that shouldn't be happening when I try to use it with an adapted multiplexer code. Like it said that 'Udp' does not have an end type, for a piece of standard Udp code that's the same no matter what example you use. I know I must have overlooked something. Regardless, now I need to see if I can get the working LIS3DH code put together with the FSR multiplexer. Edit2: I DID IT!!!!!! I figured out how to make both the multiplexer and the LIS3DH wireless in the same code! In the end I think it's more similar to the wireless mux code than the other wireless Adafruit LIS3DH dancer code. Whatever went wrong with the LIS3DH before, isn't happening now. However, the dancer code did provide an example of how to handle multiple messages being spent. I learnt from it that this code needs to be put in place after each sensor (or in the case of the mux, after the whole mux): Udp.beginPacket(outIp, outPort); msg.send(Udp); Udp.endPacket(); msg.empty(); delay(5); I also learnt from the dance code that the "msg.(whatever) can actually be named anything for each sensor. So for the mux I have it as "msgmux" and for the LIS3DH I have it as "msglis". 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! 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  |
Welcome!Here is where I blog about my progress with my Masters thesis. It is in no way meant to be "official" or in academic lingo. It's meant for me to quickly jot down my ideas and it helps when I go back to write the dissertation in the end, Archives
April 2020
Categories |
RSS Feed
