https://community.wolfram.com RSS Feed for Wolfram Community showing any discussions tagged with Connected Devices sorted by most likes. https://community.wolfram.com/groups/-/m/t/418132 *NOTE: the main tutorial notebook is attached at the end of this post and [can be downloaded by clicking here][1].* ---------- I wanted to share the attached *Mathematica* notebook that I created for teaching kids (ages 9-14) about the Wolfram Language on the Raspberry Pi. It has a simplified (and colorful) interface for students and easy editing tools for teachers to create new content (even those with little or no experience using *Mathematica*). I am extremely grateful for the efforts of Anna Musser who very patiently helped me refine the interface over many iterations and piloted the first workshops using this notebook at Empow Studios! It includes a self-paced tutorial designed for beginning programmers who are young or young-at-heart. It also includes instructions for authoring your own tutorials. The interface is minimally dynamic so the tutorial will run as smooth as possible on the Raspberry Pi model B; if there is interest, then we could build a prettier dynamic interface for more powerful hardware. Please comment below with any improvements/changes that you would like to see and of course please comment or upvote if you find this useful or interesting :) ---------- ## Sample of the attached tutorial: ![enter image description here][2] **COMPLETE TUTORIAL NOTEBOOK ATTACHED BELOW** [1]: https://www.dropbox.com/s/mddbex45h7ynao3/FirstCourseOnRPI.nb?dl=1 [2]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-12-05at11.46.57AM.png&userId=11733 Kyle Keane 2015-01-07T18:16:20Z https://community.wolfram.com/groups/-/m/t/246929 Triggered by a leak in my hot water boiler at home I built a thermal imaging camera using an Arduino and interfacing it with Mathematica. I tried to make up for the "one-pixel-resolution" by using Mathematica's powerful image analysis abilities. This is a work in progress and I would be delighted to get some comments/suggestions from the Community. In this project, I had a lot of help from [url=http://community.wolfram.com/web/bschelter/home]Bjoern Schelter[/url], who has recently joined this Community. If you have the components and use the programs below, you should have a "working" one-pixel thermal camera after 30 minutes or so of DIY. Here's a sneak peek of what we want to get out (this one is a "selfie"): [img=width: 426px; height: 270px;]/c/portal/getImageAttachment?filename=asdwefasdcsdvvafe2345QT.PNG&userId=11733[/img] I use the following components:[list=1] [*]Arduino Uno R3 [*][url=http://www.amazon.co.uk/XINTE-MLX90614ESF-DCI-non-contact-Infrared-Temperature/dp/B00IMU0LXG/ref=sr_1_2?ie=UTF8&qid=1399153918&sr=8-2&keywords=Melexis]MELEXIS / MLX90614ESF-DCI / DS Digital non-contact Infrared Temperature Sensor[/url]  (~ £35 and more or less the same in USD) [*][url=http://www.amazon.co.uk/MG995-Servo-Sensor-Mount-Black/dp/B00EZIYCUW/ref=sr_1_3?ie=UTF8&qid=1399153991&sr=8-3&keywords=Pan+tilt]MG995 Servo Sensor Mount Kit 2 DOF Pan and Tilt Black[/url] (~ £24, similar in USD) [*]Two 4.7 kOhm resistors. [*]One 0.1 uF capacitor. [*]One small breadboard. [*]5V power source. [*]Wires.  [/list]The idea is illustrated in this [url=http://www.youtube.com/watch?v=rcTKVOzxCmw]Youtube video[/url]. To my best knowledge, the original idea comes from a [url=http://www.theimagingsource.com/en_US/blog/posts/20090622/]project of Steffen Strobel in the German science competition "Jugend Forscht"[/url]. The main idea is to mount a non-contact temperature sensor on a pan and tilt mechanism (i.e. two servos) on a tripod. An Arduino microcontroller is then used to communicate via the serial port with Mathematica, which is used to control the servos and triggers the measurements. After the data acquisition Mathematica cleans the data and produces some thermal images (see below). We use the following wiring diagram to connect the servos and the temperature sensor to the Arduino. [center][img=width: 300px; height: 203px;]/c/portal/getImageAttachment?filename=ThermoCam.jpg&userId=48754[/img][/center] The resistors are 4.7kOhm and the capacitor is 0.1uF. The sensor part is taken from the [url=http://bildr.org/2011/02/mlx90614-arduino/]bildr.blog[/url], which also shows how to make Arduino talk to the sensor. The Melexis sensor that we chose has a temperature resolution of 0.02 degrees Celsius and a rather narrow field of view, which is important for our application.  For the servo part, we use the standard servo.h library; an example of its application can be found [url=http://arduino.cc/en/Tutorial/sweep]here[/url]. Here is a photo of the sensor/head of the device. [center][img=width: 320px; height: 240px;]/c/portal/getImageAttachment?filename=photo.JPG&userId=48754[/img][/center] The entire device looks like this. [center][img=width: 240px; height: 320px;]/c/portal/getImageAttachment?filename=7033photo4.JPG&userId=48754[/img][/center] The idea is to use Mathematica to send instructions to the servos and to initiate the measurements. To interface Mathematica with Arduino we use the [url=http://library.wolfram.com/infocenter/Demos/5726/]SerialIO package[/url]. I found [url=http://williamjturkel.net/2011/12/25/connecting-arduino-to-mathematica-on-mac-os-x-with-serialio/]this website by William Turkel[/url] very useful to make SerialIO work on my Mac; following the steps and adapting some directories makes the package work without any problems. At that point, we have everything in place, and only need to put the bits together. We first need to upload this piece of code (also attached at the bottom) to the Arduino. [code]#include <i2cmaster.h> #include <Servo.h> //Servo setup int servoPin1 = 9; int servoPin2 = 10; Servo servo1; Servo servo2; int angle1 = 40; // servo start positions in degrees int angle2 = 50; //Melexis setup int sensor = 0; int inByte = 0; void setup() { Serial.begin(9600); // attach pan-tilt servos servo1.attach(servoPin1); servo2.attach(servoPin2); servo1.write(angle1); servo2.write(angle2); //Initialise the i2c bus i2c_init(); PORTC = (1 << PORTC4) | (1 << PORTC5);//enable pullups establishContact(); } void loop() { if (Serial.available() > 0) { inByte = Serial.read(); int dev = 0x5A<<1; int data_low = 0; int data_high = 0; int pec = 0; i2c_start_wait(dev+I2C_WRITE); i2c_write(0x07); // read i2c_rep_start(dev+I2C_READ); data_low = i2c_readAck(); //Read 1 byte and then send ack data_high = i2c_readAck(); //Read 1 byte and then send ack pec = i2c_readNak(); i2c_stop(); //This converts high and low bytes together and processes temperature, MSB is a error bit and is ignored for temps double tempFactor = 0.02; // 0.02 degrees per LSB (measurement resolution of the MLX90614) double tempData = 0x0000; // zero out the data int frac; // data past the decimal point // Serial.print(tempData); // Serial.write(inByte); // This masks off the error bit of the high byte, then moves it left 8 bits and adds the low byte. tempData = (double)(((data_high & 0x007F) << 8) + data_low); tempData = (tempData * tempFactor)-0.01; //inByte = (float)(((data_high & 0x007F) << 8) + data_low); float celsius = tempData - 273.15; sensor=(int)(celsius*100); //float fahrenheit = (celsius*1.8) + 32; Serial.print(sensor); // horizontal "H"-> 72; reverse "R"-> 82; vertical "V"-> 86; end "E"-> 69 if(inByte==72) { angle1=angle1+1; servo1.write(angle1); } if(inByte==82) { angle1=40; servo1.write(angle1); } if(inByte==86) { angle2=angle2+1; servo2.write(angle2); } if(inByte==69) { angle1 = 40; // servo back to start angle2 = 50; servo1.write(angle1); servo2.write(angle2); } delay(15); // 15 works; wait 15 milliseconds before printing again } } void establishContact() { while (Serial.available() <= 0) { Serial.print('A'); delay(100); } } [/code] The idea is to make Mathematica communicate with the Arduino via the serial connection. The Arduino sketch shows that Ardunio is waiting for instructions, e.g. "H" to move horizontally, "V" to move vertically and "E" to go to the end position.  [mcode](*First we load the SerialIO package. See instructions above.*) << SerialIO` (*We test whether Mathematica's applications folder is in the Path. On some Macs Mathematica will be in the /Library directory - used in this example- and in others in the /Users/username/Library directory, where "username" needs to be replaced by the correct user name.*) MemberQ[$Path, "/Library/Mathematica/Applications"] (*If this gives True all is fine. If it evaluates to False execute AppendTo[$Path, "/Library/Mathematica/Applications"] *) (*Connect to the Arduino*) myArduino = SerialOpen[Quiet[FileNames["tty.usb*", {"/dev"}, Infinity]][[1]]]; SerialSetOptions[myArduino, "BaudRate" -> 9600]; While[SerialReadyQ[myArduino] == False, Pause[0.1]]; (*Data collection, in this case 40 vertical and 70 horizontal pixels; runtime 2-3 minutes; pauses cannot be reduced much further.*) pixels = {}; SerialRead[myArduino]; For[j = 1, j < 41, j++, For[i = 1, i < 71, i++, SerialWrite[myArduino, "H"]; AppendTo[pixels, (SerialRead[myArduino] // ToExpression)/100.]; Pause[0.1]]; SerialWrite[myArduino, "R"]; SerialWrite[myArduino, "V"]; SerialRead[myArduino]; Pause[0.1];]; SerialWrite[myArduino, "E"]; (*After the data aquisition close the connection to Arduino*) SerialClose[myArduino] (*Now we can use several different ways to represent the data, note that some point at the beginning/end of the scanned lines are removed; there were too many measurements errors just after the "carriage return"*) ArrayPlot[Partition[Reverse[pixels], 70][[All, 2 ;; -10]],  ColorFunction -> "Rainbow"] (*here's another colour scheme.*) ArrayPlot[Partition[Reverse[pixels], 70][[All, 2 ;; -10]], (*Occasionally there are some outliers in the measurements; here we clean them out.*) ArrayPlot[ Partition[Reverse[pixels /. x_ /; x > 35. -> 35.], 70][[All,  2 ;; -10]], ColorFunction -> "Temperature"] ColorFunction -> "Temperature"] (*This last one uses interpolation to make the image smoother.*) ListContourPlot[ Partition[Reverse[Log /@ pixels /. x_ /; x > 35. -> 35.], 70][[-1 ;; 1 ;; -1, 1 ;; -10]], AspectRatio -> 0.9, ColorFunction -> "Rainbow", PlotRange -> All, InterpolationOrder -> 2, Contours -> 60, ContourStyle -> None][/mcode][center][/center]So here's a photo of my broken boiler and its scan: [center][img=width: 518px; height: 257px;]/c/portal/getImageAttachment?filename=BoilerScan.jpg&userId=48754[/img][/center] Because of the scanning procedure (which just looks at the angle and does not use any projection), the scan is slightly distorted, but it is possible to recognize the main features and even the sticker on the front! It appears that this rather primitive device can also be used to analyse electrical components. Here is an image of my MacBook Pro. [center][img=width: 450px; height: 306px;]/c/portal/getImageAttachment?filename=Laptop1.jpg&userId=48754[/img][/center]  The position of the CPU becomes quite obvious. There are many things that need to be improved: (i) First, there is the projection issue. The scanner does scan angles. It needs to be projected to a 2D plane. One might use an ultrasonic distance sensor to get better results. (ii) The device needs to be calibrated. (iii) A user interface is needed. It would be useful to click on the image and get the temperature reading. (iv) The communication between Mathematica and the Arduino need to be improved. The starting position of 40/50 degrees is hard-coded into the Arduino sketch. It should be done by the Mathematica code. (v) We have not even started to use Mathematica's features on this. Much image processing could be done. The image should be overlayed to a normal photo of the object that is scanned. Manipulate could be used to change thresholds, i.e. the threshold to cut-off outliers, which is currently set to 35 degrees.  (vi) The speed might be improved. I suppose that the scanning time of 3 minutes or so is typical for these devices, but one might improve that a bit. Also, Mathematica could use edge-detection to determine regions where a higher scan density would be helpful to get a better resolution. This only makes sense if the servos could be directed to a certain position much more precisely; alternatively, we could use random positions, which then are precisely determined using an accelerometer or so. There is of course much more to do. In spite of this being work in progress, I wanted to share this project, and hope for helpful comments. I attach the Mathematica notebook. I have a movie of the scanning process and the actual arduino sketch which I cannot upload directly. Here are links to the [url=https://www.dropbox.com/s/sm2prb5w0wrqexp/ThermoCamera_Forum.zip]arduino sketch[/url] and the [url=https://www.dropbox.com/s/wpgpww8a7jhjfn0/Scan.MOV]scanning movie[/url]. M. Marco Thiel 2014-05-04T00:48:33Z https://community.wolfram.com/groups/-/m/t/344278 Many fantastic posts in this community describe how to connect external devices to Mathematica and how to read the data. Connecting Mathematica to an Arduino for example allows you to read and then work with data from all kinds of sensors. In most of the cases, when we speak about connected devices, additional hardware is necessary. Smart phones, on the other hand, are our permanent companions and they host a wide array of sensors that we can tap into with Mathematica. For this post, I will be using an iPhone 5 - but a similar approach can be taken with many other smart phones. [Björn Schelter][1] and myself have worked on this together. The first thing we need in order to be able to read the iPhone is a little App which can be purchased on the iTunes App store: it is called [Sensor Data][2]. When you open the app you see a screen like this one. ![enter image description here][3] At the top of the screen you see an IP address and a port number (after the colon!). These numbers will be important to connect to the phone and either download data or stream sensor data directly. If you click on the "start capture" the iPhone's data will be stored on the phone and can be downloaded into Mathematica. In this post we are rather interested in the "Streaming" function. If you click on the respective button on the bottom you get to a screen like this: ![enter image description here][4] There you can choose a frequency for the measurements and start the streaming. In fact we also can choose which sensors we want to use with the Config button. ![enter image description here][5] The following Mathematica code will work when all (!) sensors are switched on. Now we are ready to connect to the iPhone. Switch the streaming on and execute the following commands: ClearAll["Global`*"]; For[i = 1, i < 3, i++, Quiet[InstallJava[]]]; Needs["JLink`"] and then LoadJavaClass["java.util.Arrays"]; packet = JavaNew["java.net.DatagramPacket", JavaNew["[B", 1024], 1024]; socket = JavaNew["java.net.DatagramSocket", 10552]; socket@setSoTimeout[10]; listen[] := If[$Failed =!= Quiet[socket@receive[packet], Java::excptn], record =JavaNew["java.lang.String", java`util`Arrays`copyOfRange @@ packet /@ {getData[], getOffset[], getLength[]}]@toString[] // Sow]; Next we have to define a ScheduledTask to read the sensors: RemoveScheduledTask[ScheduledTasks[]]; results = {}; RunScheduledTask[AppendTo[results, Quiet[Reap[listen[]][[2, 1]]]]; If[Length[results] > 1200, Drop[results, 150]], 0.01]; We also need to define a streaming function: stream := Refresh[ToExpression[StringSplit[#[[1]], ","]] & /@ Select[results[[-1000 ;;]], Head[#] == List &], UpdateInterval -> 0.01] Alright. Now comes the interesting part. Using (*Compass*) While[Length[results] < 1000, Pause[2]]; Dynamic[AngularGauge[Refresh[stream[[-1, 30]], UpdateInterval -> 0.01], {360, 0}, ScaleDivisions -> None, GaugeLabels -> {Placed["N", Top], Placed["S", Bottom], Placed["E", Right], Placed["W", Left]}, ScaleOrigin -> {{5 Pi/2, Pi/2}, 1}, ScalePadding -> All, ImageSize -> Medium], SynchronousUpdating -> False] we can measure the bearing of our iPhone. The resulting compass moves as we move the iPhone: ![enter image description here][6] We can also read the (x-,y-,z-) accelerometers (*Plot Ascelerometers*) While[Length[results] < 1000, Pause[2]]; Dynamic[Refresh[ListLinePlot[{stream[[All, 2]], stream[[All, 3]], stream[[All, 4]]}, PlotRange -> All], UpdateInterval -> 0.1]] which gives plots like this one: ![enter image description here][7] The update is a bit bumpy, because the data is only sent every second or so from the iPhone; the measurements, however, are taken with a frequency of up to 100Hz. We can also represent the FFT of the streamed data like so: (*Plot FFT of accelorometers*) While[Length[results] < 1000, Pause[2]]; Dynamic[ Refresh[ListLinePlot[ Log /@ {Abs[Fourier[Standardize[stream[[All, 2]]]]], Abs[Fourier[Standardize[stream[[All, 3]]]]], Abs[Fourier[Standardize[stream[[All, 4]]]]]}, PlotRange -> {{0, 200}, {-5, 2.5}}, ImageSize -> Large], UpdateInterval -> 0.1]] Adding a "real time" scale is also quite straight forward: (*Measurements with time scale*) While[Length[results] < 1000, Pause[2]]; starttime = IntegerPart[stream[[2, 1]]]; Dynamic[Refresh[ ListLinePlot[ Transpose[{(stream[[Max[-300, -Length[stream]] ;;, 1]] - starttime), stream[[Max[-300, -Length[stream]] ;;, 2]]}], PlotRange -> All, ImageSize -> Large], UpdateInterval -> 0.01]] Well, then. We can also plot our iPhone's position in space (*3d Motion*) While[Length[results] < 1000, Pause[2]]; Dynamic[ Refresh[ListLinePlot[{stream[[All, 5]], stream[[All, 6]], stream[[All, 7]]}, PlotRange -> All], UpdateInterval -> 0.1]] While[Length[results] < 1000, Pause[2]]; Dynamic[ Graphics3D[{Black, Rotate[Rotate[ Rotate[Cuboid[{-2, -1, -0.2}, {2, 1, 0.2}], stream[[-1, 7]], {0, 0, 1}], -1*stream[[-1, 6]], {0, 1, 0}], stream[[-1, 5]], {1, 0, 0}]}, PlotRange -> {{-3, 3}, {-3, 3}, {-3, 3}}, Boxed -> True], UpdateInterval -> 0.1, SynchronousUpdating -> False] This looks like so: ![enter image description here][8] Last but not least we can write a little GUI to access all different sensors. (This does run a bit slow though!) (*GUI all sensors*) sensororder = {"Timestamp", "Accel_X", "Accel_Y", "Accel_Z", "Roll", "Pitch", "Yaw", "Quat.X", "Quat.Y", "Quat.Z", "Quat.W", "RM11", "RM12", "RM13", "RM21", "RM22", "RM23", "RM31", "RM32", "RM33", "GravAcc_X", "GravAcc_Y", "GravAcc_Z", "UserAcc_X", "UserAcc_Y", "UserAcc_Z", "RotRate_X", "RotRate_Y", "RotRate_Z", "MagHeading", "TrueHeading", "HeadingAccuracy", "MagX", "MagY", "MagZ", "Lat", "Long", "LocAccuracy", "Course", "Speed", "Altitude", "Proximity"}; While[Length[results] < 1000, Pause[2]]; Manipulate[ Dynamic[Refresh[ ListLinePlot[{stream[[All, Position[sensororder, a][[1, 1]]]], stream[[All, Position[sensororder, b][[1, 1]]]], stream[[All, Position[sensororder, c][[1, 1]]]]}, PlotRange -> All, ImageSize -> Full], UpdateInterval -> 0.01]], {{a, "Accel_X"}, sensororder}, {{b, "Accel_Y"}, sensororder}, {{c, "Accel_Z"}, sensororder}, ControlPlacement -> Left, SynchronousUpdating -> False] This gives a user interface which looks like this: ![enter image description here][9] In the drop down menu we can choose three out of all sensors. These are all available sensors: > "Timestamp", "Accel_X", "Accel_Y", "Accel_Z", "Roll", "Pitch", "Yaw", > "Quat.X", "Quat.Y", "Quat.Z", "Quat.W", "RM11", "RM12", "RM13", > "RM21", "RM22", "RM23", "RM31", "RM32", "RM33", "GravAcc_X", > "GravAcc_Y", "GravAcc_Z", "UserAcc_X", "UserAcc_Y", "UserAcc_Z", > "RotRate_X", "RotRate_Y", "RotRate_Z", "MagHeading", "TrueHeading", > "HeadingAccuracy", "MagX", "MagY", "MagZ", "Lat", "Long", > "LocAccuracy", "Course", "Speed", "Altitude", "Proximity" There are certainly any things that can and should be improved. The main problem seems to be that the data, even if sampled at 100Hz, is sent to the iPhone only every second or so. So it is not really real time. I hope that someone who is better at iPhone programming than I am - I am really rubbish at it- could help and write an iPhone program to stream the data in a more convenient way: one by one rather than in packets. There are many potential applications for this. Here are some I could come up with: 1. You can carry the iPhone around and measure your movements (acceleration). Attached to your hand you can measure your tremor. 2. The magnetometer is really cool. You can use it to find metal bars in the walls an also electric cables. 3. You can collect GPS data for all sorts of applications; there are ideas to use this for the detection of certain diseases. For example if it takes you longer than usual to find your car when you come from shopping that might hint at early stages of dementia --- or sleep deprivation. 4. When you put the phone on a machine, like a running motor, you can measure the vibrations. When you perform a frequency analysis you can check whether the motor runs alright. 5. Using the accelerometers I was able to measure my breathing (putting the phone on my chest). I think that there might also be quite some potential for using the Wolfram Cloud here. Deploying a program in the cloud and reading from your phone is certainly quite interesting. The problem is that this particular app only works via WiFi. It would be nice to have one that works via 3G. So, in summary, it might be quite useful to use the iPhone's sensors. The advantage is that nearly everyone carries a smartphone with them all the time. Making more of your smart phone's sensors with Mathematica seems to be a nice playground for applications. I'd love to hear about your ideas... Cheers, Marco PS: When you are done with the streaming you should execute these commands: (*Remove Scheduled Tasks and close link*) RemoveScheduledTask[ScheduledTasks[]]; socket@close[]; [1]: http://community.wolfram.com/web/bschelter [2]: https://itunes.apple.com/gb/app/sensor-data/id397619802?mt=8 [3]: /c/portal/getImageAttachment?filename=sensorwelcome.PNG&userId=48754 [4]: /c/portal/getImageAttachment?filename=sensorstreaming.PNG&userId=48754 [5]: /c/portal/getImageAttachment?filename=Allsensors.PNG&userId=48754 [6]: /c/portal/getImageAttachment?filename=Compass.gif&userId=48754 [7]: /c/portal/getImageAttachment?filename=Accelerometer.gif&userId=48754 [8]: /c/portal/getImageAttachment?filename=Iphonemovement.gif&userId=48754 [9]: /c/portal/getImageAttachment?filename=ScreenShot2014-09-15at23.52.46.png&userId=48754 Marco Thiel 2014-09-15T23:53:14Z https://community.wolfram.com/groups/-/m/t/789911 The [international year of light][1] has just drawn to an end. From 4-6 February the [closing ceremony][2] took place in [Merida, Yukatan][3]. GeoGraphics[GeoMarker[Entity["City", {"Merida", "Yucatan", "Mexico"}]], GeoRange -> Quantity[3000, "Kilometers"], GeoBackground -> "ReliefMap"] ![enter image description here][4] The international Year of Light was a global initiative of the United Nations to celebrate light and light based technologies. Mathematica's built-in Wikipedia data contains detailed information on the Year of Light; here is the first sentence of the article. TextSentences[WikipediaData["Year of Light"]][[1]] > The International Year of Light and Light-based Technologies, 2015 > (IYL 2015) is a United Nations observance that aims to raise > awareness of the achievements of light science and its applications, > and its importance to humankind. I am planning to write three posts to show how the Wolfram Language, its wealth of data, and connected devices can be used to keep the year of light alive at your home. In this first part, I will use a spectrometer, connect it to the Wolfram Language, and try to "see the world in a different light". It turns out that the Wolfram Language will be as important as the hardware for this project. Light is key to life on earth and sight is a key sense; most of the information our brains process comes from our vision. When the first organism developed primitive vision, that was an enormous evolutionary advantage, allowing them to escape preditors and localise prey. Light plays a crucial role in our modern lifes - most likely the information on this very website was delivered to you using optical fibres and light. Light also allows us to study everything from the smallest particles up to the farthest reaches of the universe. In the 17th century Sir Isaac Newton introduced the word "spectrum" into optics, referring to the range of colours observed whey light passed through a prism. Today spectrometers are used in many scientific labs to study everything from molecules to the light of stars. In this Community several posts have described the construction of [spectrometers][5] and [raspberry pi spectrometers][6]. For this blog I will use a commercial, small spectrometer, the [C12666MA Micro-Spectrometer][7], that attaches to an [Arduino Uno][8]. Hooking it up to the Arduino is trivial as the pins nicely align. ![enter image description here][9] I will first upload the following code to the Arduino: // This code is a modified from the original sketch from Peter Jansen // https://github.com/tricorderproject/arducordermini // This code removes the external ADC and uses the internal ADC instead. // also this code just prints the output to csv output to the terminal. #define SPEC_GAIN A0 //#define SPEC_EOS NA #define SPEC_ST A1 #define SPEC_CLK A2 #define SPEC_VIDEO A3 #define WHITE_LED A4 #define LASER_404 A5 #define SPEC_CHANNELS 256 uint16_t data[SPEC_CHANNELS]; void setup() { //pinMode(SPEC_EOS, INPUT); pinMode(SPEC_GAIN, OUTPUT); pinMode(SPEC_ST, OUTPUT); pinMode(SPEC_CLK, OUTPUT); pinMode(WHITE_LED, OUTPUT); pinMode(LASER_404, OUTPUT); digitalWrite(WHITE_LED, LOW); digitalWrite(LASER_404, LOW); //digitalWrite(WHITE_LED, HIGH); //digitalWrite(LASER_404, HIGH); digitalWrite(SPEC_GAIN, HIGH); digitalWrite(SPEC_ST, HIGH); digitalWrite(SPEC_CLK, HIGH); digitalWrite(SPEC_GAIN, HIGH); //LOW Gain //digitalWrite(SPEC_GAIN, LOW); //High Gain //Serial.begin(9600); Serial.begin(115200); } void readSpectrometer() { //int delay_time = 35; // delay per half clock (in microseconds). This ultimately conrols the integration time. int delay_time = 1; // delay per half clock (in microseconds). This ultimately conrols the integration time. int idx = 0; int read_time = 35; // Amount of time that the analogRead() procedure takes (in microseconds) (different micros will have different times) int intTime = 5; int accumulateMode = false; int i; // Step 1: start leading clock pulses for (int i = 0; i < SPEC_CHANNELS; i++) { digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); } // Step 2: Send start pulse to signal start of integration/light collection digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); digitalWrite(SPEC_ST, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); digitalWrite(SPEC_ST, HIGH); delayMicroseconds(delay_time); // Step 3: Integration time -- sample for a period of time determined by the intTime parameter int blockTime = delay_time * 8; long int numIntegrationBlocks = ((long)intTime * (long)1000) / (long)blockTime; for (int i = 0; i < numIntegrationBlocks; i++) { // Four clocks per pixel // First block of 2 clocks -- measurement digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); } // Step 4: Send start pulse to signal end of integration/light collection digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); digitalWrite(SPEC_ST, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); digitalWrite(SPEC_ST, HIGH); delayMicroseconds(delay_time); // Step 5: Read Data 2 (this is the actual read, since the spectrometer has now sampled data) idx = 0; for (int i = 0; i < SPEC_CHANNELS; i++) { // Four clocks per pixel // First block of 2 clocks -- measurement digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, LOW); // Analog value is valid on low transition if (accumulateMode == false) { data[idx] = analogRead(SPEC_VIDEO); } else { data[idx] += analogRead(SPEC_VIDEO); } idx += 1; if (delay_time > read_time) delayMicroseconds(delay_time - read_time); // Read takes about 135uSec digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); // Second block of 2 clocks -- idle digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); } // Step 6: trailing clock pulses for (int i = 0; i < SPEC_CHANNELS; i++) { digitalWrite(SPEC_CLK, LOW); delayMicroseconds(delay_time); digitalWrite(SPEC_CLK, HIGH); delayMicroseconds(delay_time); } } void print_data() { for (int i = 0; i < SPEC_CHANNELS; i++) { Serial.print(data[i]); Serial.print(','); } Serial.print("\n"); } void loop() { // digitalWrite(LASER_404, HIGH); // readSpectrometer(); // digitalWrite(LASER_404, LOW); // print_data(); // delay(10); // digitalWrite(WHITE_LED, HIGH); // readSpectrometer(); // digitalWrite(WHITE_LED, LOW); // print_data(); // delay(10); readSpectrometer(); print_data(); delay(10); } The Arduino code is quite long and I first thought to only attach it to the post, but there is a particular line which is important. In the "void readSpectrometer()" part there is the line int intTime = 5; which allows you to set the integration time, i.e. the exposure time. That is a very important parameter to get optimal results. With the new features of the *Wolfram Language* and in particular with the [Arduino Device Connection][10] it is possible to adjust the exposure from within the Wolfram Language code. For this post this is not really necessary, so I will save that for another day. Connecting the Arduino-Spectrometer duo to Mathematica is trivial. Here I connect it to an OSX system. mySpectrometer = DeviceOpen["Serial", {Quiet[FileNames["tty.usb*", {"/dev"}, Infinity]][[1]], "BaudRate" -> 115200}] This piece of code Quiet[FileNames["tty.usb*", {"/dev"}, Infinity]][[1]] facilitates the connection as it detects the correct device automatically. We can now start collecting data like so: data = Table[Pause[2]; ToExpression /@ StringSplit[FromCharacterCode[SplitBy[DeviceReadBuffer[mySpectrometer], # == 10 &][[-2]]], ","], {i, 6}]; This data aquisition code actually measures 6 spectra and pauses for 2 seconds between individual measurements. These repeated measurements decrease the noise of the measurements. The measurement procedure is very straight foward. You point the spectrometer at an object and execute the data aquisition. Let's fist look at the spectrum of a fluorescent light bulb. ListLinePlot[N@Mean[Select[data, Length[#] == 256 &]], PlotRange -> All] ![enter image description here][11] There are several peaks that we will try to understand a little bit later. The x-axis shows 256 bins which represent the different colours, i.e. frequencies. The y-axis shows the count, i.e. the intensity of that frequency band. In oder to be able to interpret the results we first need to calibrate the spectrometer. Here is a link to a table which contains calibration information for various versions of the spectrometer. It turns out that the calibration is performed using a 5th order polynomial; the repective coefficients are given in [the calibration table][12]. For my particular spectrometer I obtain: a0 = 3.170083173*10^2; b1 = 2.39519817; b2 = -8.618615345*10^(-4); b3 = -5.978279712*10^(-6); b4 = 8.585352787*10^(-9); b5 = -2.048534811*10^(-12); wavelength[x_] := a0 + b1 x + b2 x^2 + b3 x^3 + b4*x^4 + b5 x^5 Here is a plot of the calibration curve: Plot[{wavelength[x]}, {x, 0, 256}] ![enter image description here][13] It transforms the number of the bin to the corresponding wavelength. We can not plot the spectrum with the correct x-axis. datacalibrated = Transpose@{wavelength /@ Range[256], N@Mean[Select[data, Length[#] == 256 &]]}; ListLinePlot[datacalibrated, PlotRange -> All] ![enter image description here][14] This is much better. This is how a professional spectrum of a fluorescent light bulb looks like: ![enter image description here][15] which is taken from the [Wikipedia commons][16]. Here is a list of the peaks and what element they correspond to: ![enter image description here][17] We clearly see the peaks for Mercury, Terbium and Europium. Wolfram|Alpha has a wealth of information about spectral lines and we can use the following line to get it. WolframAlpha["spectral lines mercury"] ![enter image description here][18] The two dominant lines here are the one at 4046.565 Angstrom and at 4358.335 Angstrom. They correspond to our lines at about 405 nm and 436 nm. Unfortunately, I have failed to extract a list of all relevant spectral lines from Wolfram|Alpha. Let's try to spice our representation of the spectrum up a bit. It would be nice to have a visual cue as to the colour the different wavelengths correspond to. Mathematica and the Wolfram Language have everything built in to make this task really easy: ColorData["VisibleSpectrum"][#] & /@ datacalibrated[[All, 1]] ![enter image description here][19] We can now merge this into a band of colours that we can plot with the spectrum. Graphics[Table[{ColorData["VisibleSpectrum"][datacalibrated[[i, 1]]], Rectangle[{datacalibrated[[i, 1]], 0}, {datacalibrated[[i + 1, 1]],40}]}, {i, 1, Length[datacalibrated] - 1}]] ![enter image description here][20] If we plot this together things start being easier to interpret. Show[ListLinePlot[datacalibrated, PlotRange -> All], Graphics[Table[{ColorData["VisibleSpectrum"][datacalibrated[[i, 1]]], Rectangle[{datacalibrated[[i, 1]], 10}, {datacalibrated[[i + 1, 1]], 40}]}, {i, 1, Length[datacalibrated] - 1}]]] ![enter image description here][21] Now there are two more things I want to tweak. First of all there is this off-set of 54; that is a "zero count", i.e. I obtain at least 54 even if there is no signal so I need to subtract that. This number depends on the spectrometer that you have. On a second one I have got that value is different. Also, I would like the lightcurve itself to reflect the colour. The following code achieves that: Show[ListLinePlot[Evaluate@(Plus[{0., -54.}, #] & /@ datacalibrated), PlotRange -> {All, {-30, All}}, Joined -> True, Frame -> True, ColorFunction -> (Blend["VisibleSpectrum", #1* Differences[datacalibrated[[All, 1]][[{1, -1}]]][[1]] + datacalibrated[[1, 1]]] &), Filling -> Axis, LabelStyle -> Directive[Black, Bold, Medium], FrameLabel -> {"Wavelength (nm)", "Intensity"}], Graphics[Table[{ColorData["VisibleSpectrum"][datacalibrated[[i, 1]]], Rectangle[{datacalibrated[[i, 1]], -30}, {datacalibrated[[i + 1, 1]], -10}]}, {i, 1, Length[datacalibrated] - 1}]]] ![enter image description here][22] To identify the spectral lines it is useful to identify maxima of the curve. The following function helps to achieve that: localMaxPositions = Compile[{{pts, _Real, 1}}, Module[{result = Table[0, {Length[pts]}], i = 1, ctr = 0}, For[i = 2, i < Length[pts], i++, If[pts[[i - 1]] < pts[[i]] && pts[[i + 1]] < pts[[i]],result[[++ctr]] = i]];Take[result, ctr]]]; We can now locate the maxima and plot that on the curve: dplot = ListLinePlot[datacalibrated, PlotRange -> All]; maxs = ListPlot[Select[Nest[#[[localMaxPositions[#[[All, 2]]]]] &, datacalibrated, 1], #[[2]] > 58.33 &], PlotStyle -> Directive[PointSize[0.015], Green]]; Show[{dplot, maxs}] ![enter image description here][23] The following function produces a list of the positons of the maxima: Select[Nest[#[[localMaxPositions[#[[All, 2]]]]] &, datacalibrated, 1], #[[2]] > 58.33 &][[All, 1]] (*{366.873694406445`,406.4710188519941`,436.1860721777116`,489.\ 5449068238321`,544.8439203380104`,587.3854766583466`,610.\ 7844904587837`,668.0095922519685`,688.8768717778272`,707.\ 3639428495288`}*) It turns out that there is a packages which contains information about spectral lines, but the elements that we are interested in (Hg, Te, Eu) are not in the database. For elements that are in the database we can compare the measured lines to the ones in the database: << ResonanceAbsorptionLines` ElementAbsorptionMap[Na] ![enter image description here][24] What we can do, however, is to generate - or simulate- an approximatio of the spectral lines we measure. There is a [discussion on Stackexchange][25] that shows how to plot an emission spectrum. The following lines are taken from that discussion. spec[wavelength_, width_] := Flatten[Table[{{x, 0, x}, {x, 1, x}}, {x, wavelength - width, wavelength + width, 0.1}], 1]; ListDensityPlot[ spec[#, 1] & /@ Select[Nest[#[[localMaxPositions[#[[All, 2]]]]] &, datacalibrated, 1], #[[2]] > 59.33 &][[All, 1]], ColorFunction -> ColorData["VisibleSpectrum"], ColorFunctionScaling -> False, AspectRatio -> .3, PlotRange -> {{300, 800}}, FrameTicks -> {Automatic, None, None, None}, FrameTicksStyle -> White, Frame -> True, Background -> Black] ![enter image description here][26] Case Studies ============ Blue sky -------- I now measure the spectrum of the blue sky. The measurement was taken late in the year and the sky wasn't the "bluest of blues", but we can still make out some interesting features. mySpectrometer = DeviceOpen[ "Serial", {Quiet[FileNames["tty.usb*", {"/dev"}, Infinity]][[1]], "BaudRate" -> 115200}]; datasky = Table[Pause[2]; ToExpression /@ StringSplit[ FromCharacterCode[ SplitBy[DeviceReadBuffer[mySpectrometer], # == 10 &][[-2]]], ","], {i, 6}]; a0 = 3.170083173*10^2; b1 = 2.39519817; b2 = -8.618615345*10^(-4); b3 = -5.978279712*10^(-6); b4 = 8.585352787*10^(-9); b5 = -2.048534811*10^(-12); wavelength[x_] := a0 + b1 x + b2 x^2 + b3 x^3 + b4*x^4 + b5 x^5; datacalibratedsky = Transpose@{wavelength /@ Range[256], N@Mean[Select[datasky, Length[#] == 256 &]]}; Show[ListLinePlot[Evaluate@(Plus[{0., -54.}, #] & /@ datacalibratedsky), PlotRange -> {All, {-30, All}}, Joined -> True, Frame -> True, ColorFunction -> (Blend["VisibleSpectrum", #1*Differences[datacalibratedsky[[All, 1]][[{1, -1}]]][[1]] + datacalibratedsky[[1, 1]]] &), Filling -> Axis, LabelStyle -> Directive[Black, Bold, Medium], FrameLabel -> {"Wavelength (nm)", "Intensity"}], Graphics[Table[{ColorData["VisibleSpectrum"][datacalibratedsky[[i, 1]]], Rectangle[{datacalibratedsky[[i, 1]], -30}, {datacalibratedsky[[i + 1, 1]], -10}]}, {i, 1, Length[datacalibratedsky] - 1}]]] ![enter image description here][27] The spectrum clearly shows the "blue" in the sky. It turns out that the marked double dip corresponds to absorption by water. Lasers ------ Using exactly the same code we can now analyse the spectrum of different lasers - red, green and blue. We can clearly see that the red and green lasers have a very narrow peak within the red and green spectral bands, whereas the blue laser has a much broader peak. This is probably related to how blue laser light is generateed in cheap laser pointers. ![enter image description here][28] Here is how the spectrum of a red laser would look like: ListDensityPlot[ spec[#, 1] & /@ Select[Nest[#[[localMaxPositions[#[[All, 2]]]]] &, datacalibratedlaserr, 1], #[[2]] > 59.33 &][[All, 1]], ColorFunction -> ColorData["VisibleSpectrum"], ColorFunctionScaling -> False, AspectRatio -> .3, PlotRange -> {{400, 800}}, FrameTicks -> {Automatic, None, None, None}, FrameTicksStyle -> White, Frame -> True, Background -> Black] ![enter image description here][29] Absorption spectrum - green leaf -------------------------------- Up to now we have maily discussed emission spectra - apart from some features of the blue sky example. Let's now generate an absorption spectrum. In an emission spectrum a material actively emits radiation/light. In an absoprtion spectrum light that passes through the material. ![enter image description here][30] In order to produce a good absorption spectrum we would ideally use a light source that produces a strong continuous spectrum. When I conducted the leaf experiment I only had a very cheap lamp which is usually used by doctors for initial examinations: ![enter image description here][31] I pointed the lamp at a green leaf and measured the light that shone through. The problem was that the lamp did produce a very poor spectrum heavily biased towards the red frequency range. So in this case study I will first measure the emission spectrum of the lamp and then normalise the absorption spectrum of the leaf. Let's start with the lamp. mySpectrometer = DeviceOpen[ "Serial", {Quiet[FileNames["tty.usb*", {"/dev"}, Infinity]][[1]], "BaudRate" -> 115200}]; datalamp = Table[Pause[2]; ToExpression /@ StringSplit[ FromCharacterCode[ SplitBy[DeviceReadBuffer[mySpectrometer], # == 10 &][[-2]]], ","], {i, 6}]; a0 = 3.170083173*10^2; b1 = 2.39519817; b2 = -8.618615345*10^(-4); b3 = -5.978279712*10^(-6); b4 = 8.585352787*10^(-9); b5 = -2.048534811*10^(-12); wavelength[x_] := a0 + b1 x + b2 x^2 + b3 x^3 + b4*x^4 + b5 x^5; datacalibratedlamp = Transpose@{wavelength /@ Range[256], N@Mean[Select[datalamp, Length[#] == 256 &]]}; Show[ListLinePlot[Evaluate@(Plus[{0., -54.}, #] & /@ datacalibratedlamp), PlotRange -> {All, {-30, All}}, Joined -> True, Frame -> True, ColorFunction -> (Blend["VisibleSpectrum", #1*Differences[datacalibratedlamp[[All, 1]][[{1, -1}]]][[1]] + datacalibratedlamp[[1, 1]]] &), Filling -> Axis, LabelStyle -> Directive[Black, Bold, Medium], FrameLabel -> {"Wavelength (nm)", "Intensity"}], Graphics[Table[{ColorData["VisibleSpectrum"][datacalibratedlamp[[i, 1]]], Rectangle[{datacalibratedlamp[[i,1]], -30}, {datacalibratedlamp[[i + 1, 1]], -10}]}, {i, 1,Length[datacalibratedlamp] - 1}]]] ![enter image description here][32] The spectrum is clearly biased to the red freqencies. In the blue/ultraviolet range the light source produces to little output that it will be impossible to determine a reasonable absorption spectrum there. Let's go on to measure the absorption of the leaf. absorptionleaf = Transpose[{datacalibratedleaf[[All, 1]], (datacalibratedleaf[[All, 2]]/datacalibratedlamp[[All, 2]])}]; Show[ListLinePlot[Evaluate@(Plus[{0., 0.}, #] & /@ absorptionleaf), PlotRange -> {All, {-0.3, 1}}, Joined -> True, Frame -> True, ColorFunction -> (Blend["VisibleSpectrum", #1*Differences[absorptionleaf[[All, 1]][[{1, -1}]]][[1]] + absorptionleaf[[1, 1]]] &), Filling -> Axis, LabelStyle -> Directive[Black, Bold, Medium], FrameLabel -> {"Wavelength (nm)", "Intensity"}], Graphics[Table[{ColorData["VisibleSpectrum"][absorptionleaf[[i, 1]]],Rectangle[{absorptionleaf[[i, 1]], -0.3}, {absorptionleaf[[i + 1,1]], -.1}]}, {i, 1, Length[absorptionleaf] - 1}]]] ![enter image description here][33] The absorption in the red frequency range stems from chlorophyll; chlorophyll also absorbs in the 400-450nm range which is hard to se here, because of our poor light source. The dip at around 500nm is carotenoids. You can compare that to the [spectrum of leaves on this website][34]. "Black body radiation" - an old fashioned light bulb ---------------------------------------------------- The final example will be of an old fashioned, small light bulb. ![enter image description here][35] I will use a bench supply to slowly increase the voltage and the current. The filament will go from a red glowing colour to brighter "whiter" colour, but we will see that even for the highest voltage of 12V the spectrum will still be quite different from "white", i.e. uniform. The code is just the same as above. I save all plots for voltages 1V to 12V with increments of 1V in one variable: specall = {spec1V, spec2V, spec3V, spec4V, spec5V, spec6V, spec7V, spec8V, spec9V, spec10V, spec11V, spec12V} This can be easily plotted like so: Grid[Partition[specall, 4]] ![enter image description here][36] We can also animate this: ListAnimate[specall, AnimationRunTime -> 10] ![enter image description here][37] Note that from 9V onwards the spectrum has max-ed out. When I measured the spectra I took note of the voltage and the corresponding current: voltageamp = {{1, 0.04}, {2, 0.06}, {3, 0.07}, {4, 0.08}, {5, 0.1}, {6, 0.11}, {7, 0.12}, {8, 0.13}, {9, 0.14}, {10, 0.14}, {11, 0.15}, {12, 0.16}} I can now represent that with the regression line. Show[ListPlot[voltageamp, AxesLabel -> {"Volts", "Amps"}, LabelStyle -> Directive[Bold, Medium]], Plot[Evaluate@Fit[voltageamp, {1, x}, x], {x, 0, 12}, PlotStyle -> Red]] ![enter image description here][38] Note the nearly linear increase in current as the voltage increases. Finally, I took photos as the voltage increased. ![enter image description here][39] We now add a little bit of motion to the voltage amp graph: figvoltsamp = Evaluate@Table[Show[ListPlot[voltageamp, AxesLabel -> {"Volts", "Amps"}, LabelStyle -> Directive[Bold, Medium], Epilog -> {PointSize[Large], Green, Point[voltageamp[[i]]]}], Plot[Evaluate@Fit[voltageamp, {1, x}, x], {x, 0, 12}, PlotStyle -> Red]], {i, 1, 12}]; To finish everything off, we can now animate this: ListAnimate[GraphicsRow[#, ImageSize -> Full] & /@ Transpose[{specall, bulb, figvoltsamp}]] ![enter image description here][40] If we were to assume that this is the radiation of a black body, we could use Planck's law: FormulaData[{"PlanckRadiationLaw", "Wavelength"}] ![enter image description here][41] We could plot this as a function of temperature and wavelength equation = FormulaData[{"PlanckRadiationLaw", "Wavelength"}, {"T" -> Quantity[t, "Kelvins"], "\[Lambda]" -> Quantity[l, "Nanometers"]}]; Plot3D[Quantity[1.191042*^29, ("Pascals")/("Seconds")]/(-1.`16.255 l^5 + 2.71828^(1.438*^7/(l t)) l^5), {l, 300, 808}, {t, 1000, 5000}, PlotRange -> All, AxesLabel -> {"wavelength", "temperature", "luminosity"}, LabelStyle -> Directive[Bold, Medium], ImageSize -> Large] ![enter image description here][42] We can also write a little loop to calculate for which wavelength the maximum for different temperatures is reached. results = {}; Monitor[ Table[equation2 = FormulaData[{"PlanckRadiationLaw", "Wavelength"}, {"T" -> Quantity[t, "Kelvins"], "\[Lambda]" -> Quantity[l, "Nanometers"]}]; root = FindRoot[D[equation2[[2, 2]], l] == 0, {l, 700}, MaxIterations -> Infinity]; AppendTo[results, {t, root}], {t, 2800, 3400, 100}], t] This gives the following table: Grid[Join[{{"Temperature K", "\[Lambda] at max"}}, Transpose[{results[[All, 1]], results[[All, 2, -1, 2]]}]], Frame -> All] ![enter image description here][43] We can plot the relationship between maxium and temperature. ListLinePlot[Transpose[{results[[All, 1]], results[[All, 2, -1, 2]]}],Mesh -> Full, MeshStyle -> Red, AxesLabel -> {"Temperature", "wavelength at max"}, LabelStyle -> Directive[Bold, Medium], ImageSize -> Large] ![enter image description here][44] This allows us in principle to estimate the temperature of the filament. Note, that for 8V the maximum is at about 750nm. The graph shows that this corresponds to a temperature higher than 3400K, which is too high for such a small light bulb. So there is still quite some room for improvement... The principle of temperature measurement, by the colour of the sample is realistic. There are many further projects one could think of. I suppose that with a decent telescope it should be possible to analyse the light of stars for example. Also, the spectrometer works nicely on a Raspberry Pi. It should be quite straight forward to take measurements of say the sky over the day and see how the dominant colours change. Cheers, Marco [1]: http://www.light2015.org/Home.html [2]: http://www.light2015.org/Home/About/Latest-News/February2016/The-International-Year-of-Light-and-Light-based-Technologies-2015-Closing-Ceremony.html [3]: http://www.wolframalpha.com/input/?i=Merida%20Yukatan [4]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.09.22.png&userId=48754 [5]: http://community.wolfram.com/groups/-/m/t/178634 [6]: http://community.wolfram.com/groups/-/m/t/201504 [7]: https://www.tindie.com/products/PureEngineering/arduino-c12666ma-micro-spectrometer-/ [8]: https://www.arduino.cc/en/Main/ArduinoBoardUno [9]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.12.11.png&userId=48754 [10]: https://reference.wolfram.com/language/ref/device/Arduino.html [11]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.14.33.png&userId=48754 [12]: https://files.groupgets.com/hamamatsu/uspectrometer/Hama-Data-Camp-7.pdf [13]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.17.28.png&userId=48754 [14]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.18.21.png&userId=48754 [15]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.19.12.png&userId=48754 [16]: https://commons.wikimedia.org/wiki/File:Fluorescent_lighting_spectrum_peaks_labelled.svg [17]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.20.45.png&userId=48754 [18]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.21.48.png&userId=48754 [19]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.22.53.png&userId=48754 [20]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.23.52.png&userId=48754 [21]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.24.51.png&userId=48754 [22]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.26.07.png&userId=48754 [23]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.27.39.png&userId=48754 [24]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.28.48.png&userId=48754 [25]: http://mathematica.stackexchange.com/questions/85990/how-to-plot-an-emission-spectrum [26]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.30.19.png&userId=48754 [27]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.33.08.png&userId=48754 [28]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.34.36.png&userId=48754 [29]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.36.25.png&userId=48754 [30]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.37.13.png&userId=48754 [31]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.37.43.png&userId=48754 [32]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.39.26.png&userId=48754 [33]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.41.03.png&userId=48754 [34]: http://socratic.org/questions/how-does-the-visible-light-spectrum-relate-to-photosynthesis [35]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.42.16.png&userId=48754 [36]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.43.25.png&userId=48754 [37]: http://community.wolfram.com//c/portal/getImageAttachment?filename=spectrumanim.gif&userId=48754 [38]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.46.07.png&userId=48754 [39]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.46.53.png&userId=48754 [40]: http://community.wolfram.com//c/portal/getImageAttachment?filename=FinalAnimSpectrometer.gif&userId=48754 [41]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.49.46.png&userId=48754 [42]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.51.00.png&userId=48754 [43]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.52.31.png&userId=48754 [44]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2016-02-09at01.53.27.png&userId=48754 Marco Thiel 2016-02-09T02:05:38Z https://community.wolfram.com/groups/-/m/t/315748 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/4d655a10-832e-4ace-b937-6d5a702289a3 Ian Johnson 2014-08-10T17:56:06Z https://community.wolfram.com/groups/-/m/t/456947 ![Wolfram Pi Flowers][9] ---------- I will explain how to make the time-lapse animation you can see above. **1)** Set-up your [camera module][1]. I sticked mine on a hard drive, see the first image on [my previous Data Drop post][2]. ![setup][3] **2)** Take a test shot to check that the exposure is acceptable. DeviceRead["RaspiCam",{320, 240}] **3)** Adjust the resulting image with [ImageAdjust][4]. ImageAdjust[DeviceRead["RaspiCam",{320, 240}]] ![Test shot][5] **4)** Create a new databin, and take note of its short ID: CloudConnect["email-wolframID","password" ]; bin=CreateDatabin[]; bin["ShortID"] "3GgU-jf4" **5)** Setup a [ScheduledTask][6] that adds a snapshot to your databin every 360 seconds (6minutes): intervalometer=RunScheduledTask[DatabinAdd[Databin["3GgU-jf4"], ImageAdjust[DeviceRead["RaspiCam",{320, 240}]]],360] **6)** Water your plant and wait. **7)** Check that your databin is being filled correctly [http://wolfr.am/3GgU-jf4][7] ![databin][8] **8)** Compile the animated gif: frames = Values[Databin["3GgU-jf4"]]; Export["resurrected_plant.gif", Join[frames, Reverse[frames]]] **9)** Enjoy! ![Wolfram Pi Flowers][9] **10)** To stop your scheduled task, use the function [StopScheduledTask][10]: StopScheduledTask[intervalometer] [1]: http://community.wolfram.com/groups/-/m/t/157704 [2]: http://community.wolfram.com/groups/-/m/t/453169 [3]: /c/portal/getImageAttachment?filename=setupPlant.png&userId=56204 [4]: http://reference.wolfram.com/language/ref/ImageAdjust.html [5]: /c/portal/getImageAttachment?filename=FlowerFrames.jpg&userId=56204 [6]: http://reference.wolfram.com/language/ref/RunScheduledTask.html [7]: http://wolfr.am/3GgU-jf4 [8]: /c/portal/getImageAttachment?filename=databin_filled.png&userId=56204 [9]: /c/portal/getImageAttachment?filename=Wplant.gif&userId=56204 [10]: http://reference.wolfram.com/language/ref/StopScheduledTask.html Bernat Espigulé 2015-03-11T11:50:05Z https://community.wolfram.com/groups/-/m/t/196759 These sensors are pretty cool--they are [url=http://www.adafruit.com/products/374]cheap to buy[/url] and surprisingly sensitive to small changes in temperature. Here's a first attempt I made to interact with the sensors in the Wolfram Language. For this setup I used DS18B20 temperature sensors and hooked them up to the Raspberry Pi breadboard according to Adafruit's [url=http://learn.adafruit.com/adafruits-raspberry-pi-lesson-11-ds18b20-temperature-sensing/overview]setup guide[/url]. The board should look like the following diagram (make sure the sensor is hooked up to a 3.3V pin--not a 5V pin or you could fry the sensor): [center][img=width: 300px; height: 481px;]https://learn.adafruit.com/system/assets/assets/000/003/775/medium800/learn_raspberry_pi_summary.jpg[/img][/center] Once hooked up and connected to your Pi, run the following commands in the terminal: [code]sudo modprobe w1-gpio sudo modprobe w1-therm[/code] The temperatures are read from the sensor by "reading" the file that's created in the devices directory. You can locate the file with the following commands: [code]cd /sys/bus/w1/devices ls[/code] This will show you the contents of your devices folder, where there should be a file titled 28-xxxx, where the xxxx is the serial number unique to your sensor. Once you've got that number, enter: [code]cd 28-xxxx (the xxxx should be replaced with the serial number unique to your sensor) cat w1_slave[/code] Two lines of data should return back to you--if the first line ends with "YES" then the 5-digit number at the end of the second line is the temperature, to be read as xx.xxx degrees Celsius. And now that we know that the temperature sensor is working, and we know how to find it, we can copy the file path and import it using the Wolfram Language. [mcode]Import["/sys/bus/w1/devices/28-000004fe0343/w1_slave"][/mcode] Since this still returns a really long string of data that we don't need, we can single out the temperature and then convert the string into a computable expression. [mcode]temp:=N[ToExpression[StringTake[Import["/sys/bus/w1/devices/28-000004fe0343/w1_slave"],-5]]/1000][/mcode] So now when we read the file, we just get the temperature back! [mcode]temp (*22.312*) [/mcode] For kicks, I set up a scheduled task to plot the ambient temperature of my office every 60 seconds for 6 hours. Unsurprisingly, the temperature only fluctuated a few tenths of a degree...! [mcode]t={} RunScheduledTask[(deg=temp;AppendTo[t,deg]),{60,360}]; Dynamic[ListLinePlot[t,Joined->True,PlotRange->Automatic]] [/mcode] And here's what the graph looked like after a little bit of time--it truly is a sensitive device (the "large" dip down to 22.1 was me touching the sensor with my cold hands!): [center][img=width: 360px; height: 228px;]/c/portal/getImageAttachment?filename=temperaturereading3.jpg&userId=108162[/img][/center]Any suggestions for what to do next? Allison Taylor 2014-02-06T21:04:23Z https://community.wolfram.com/groups/-/m/t/250923 I thought I would share the following rather simple experiment. It is based on a Geiger counter which interacts via the serial port with Mathematica. It can be used to measure ambient levels of radioactivity and to test different radioactive sources at home. As an additional benefit it generates "perfect/physical" random numbers (as opposed to pseudorandom numbers), some of which I attach to this post.  The setup is rather simple, unfortunately one of the parts is a bit expensive. I use 1) [url=https://www.sparkfun.com/products/11345]Sparkfun's Geiger Counter SEN-11345[/url]. (about 150 $ and similar in £) 2) A USB 2.0 A/Mini-B cable. [img=width: 400px; height: 300px;]/c/portal/getImageAttachment?filename=photo5.JPG&userId=48754[/img] The Geiger tube is on the bottem right on the photo. The parts inside the dashed line are under high voltage when the thing is switched on; avoid touching any of these parts. The Geiger counter has an onboard AMTEL chip (like Arduino) so it communicate easily via the serial port. You might have to install the appropriate VCP driver [url=http://www.ftdichip.com/Drivers/VCP.htm]from this website[/url]. Once the driver is installed you connect the Geiger counter to the USB port of the computer. On the software side you need to install the [url=http://library.wolfram.com/infocenter/Demos/5726/]SerialIO package[/url]. Step by step instructions for the installation can be found on [url=http://williamjturkel.net/2011/12/25/connecting-arduino-to-mathematica-on-mac-os-x-with-serialio/]this website[/url]. The Sparkfun Geiger counter sends a sequence of 0 and 1 to the serial port, which indicate whether the previous interval is longer or shorter than the current interval between counts. Each number corresponds to one event - the counter measures alpha, beta and gamma radiation; the latter only if the red protective cap is removed. The sequence of zeros and ones can be used as a set of independent random numbers. For most simulations the pseudorandom numbers that computers (and Mathematica) generate, but for some other applications such as encryption physical random numbers are preferable. The code below will produce that string of random digits, but it will also record the times of the measured decay events. The code is for Mac OSX but can easily be adapted for other operating systems. [mcode](*Clear everything*) ClearAll["Global`*"] (*Load SerialIO*) << SerialIO` (*Connect to the Geiger counter*) myGeigerCounter = SerialOpen[Quiet[FileNames["tty.usb*", {"/dev"}, Infinity]][[1]]]; SerialSetOptions[myGeigerCounter, "BaudRate" -> 9600]; While[SerialReadyQ[myGeigerCounter] == False, Pause[0.1]]; (*Measure*) s = {}; tZero = AbsoluteTime[]; SerialRead[myGeigerCounter]; Dynamic[ Refresh[ AppendTo[s, {SerialRead[myGeigerCounter], AbsoluteTime[] - tZero}];, UpdateInterval -> 0.002], SynchronousUpdating -> False] [/mcode] That is basically the entire code for reading the data. The critical point is the UpdateInterval. If the computer is busy, it might measure too slowly and measure a sequence of 0s and 1s instead of a single digit, so it is important to have few background processes running. The UpdateInterval of 0.002 has shown to be sufficiently high for my experiments; Sparkfun's detector can measure up to 100 Hz. Also, if there is no event for 10 seconds the program will read " " and record the time, i.e. last event plus 10 seconds. Therefore we need to clean up the data after the measurement is finished (simply abort the evaluation), see below. If you want to plot the measurements dynamically you can use:  [mcode]Dynamic[sc = DeleteCases[s, {"", ___}]; ListPlot[sc[[2 ;;, 2]] - sc[[1 ;; -2, 2]], PlotRange -> {All, {0, Max[sc[2 ;;, 2]] - sc[[1 ;; -2, 2]]}}, ImageSize -> Large]][/mcode] This gives the following animation, where every couple of seconds a new point is added. [img=width: 400px; height: 240px;]/c/portal/getImageAttachment?filename=Decay-movie.gif&userId=48754[/img] If you are interested in an estimate of the "counts per minute" this command will do the trick: [mcode]Dynamic[10/(sc[[-1, 2]] - sc[[-10, 2]])*60. // N][/mcode] So by now we have a working Geiger counter and we can visualise the results.  To test the counter I ran a measurement of the background radiation for a couple of hours. I import the data: [mcode]tstest = Import["~/Desktop/Geigerdata_overnight.csv"]; [/mcode]  Then clean it up [mcode]tsBackground = DeleteCases[# & /@ tstest, {"", ___}] // ToExpression[/mcode] and plot a diagram of the time between two consecutive events [mcode]ListPlot[tsBackground[[2 ;; -1, 2]] - tsBackground[[1 ;; -2, 2]], PlotRange -> All, AxesLabel -> {"Decay Incidence", "Waiting Time"}, ImageSize -> Large][/mcode] [img=width: 576px; height: 320px;]/c/portal/getImageAttachment?filename=RadioactivityAnalysis-BackgroundWT.jpg&userId=48754[/img] There are sligthly more than 12000 events in this time series. To compare that to some radioactive object I dismantled a smoke detector and extracted the radioactive Americanum 241 container. The sourse emits alpha and gamma particles and is supposed to have a rate of about 33000 Bq, i.e. decays per second. (It says 0.9uCi on the detector. Wolfram Alpha knows that that is 33300 Bq.) [img=width: 400px; height: 300px;]/c/portal/getImageAttachment?filename=photo6.JPG&userId=48754[/img]  I position the Americanum at about 3 cm from the tip of the Geiger counter. [img=width: 400px; height: 300px;]/c/portal/getImageAttachment?filename=photo7.JPG&userId=48754[/img] I then measure the counts over a couple of hours and obtain: [img=width: 576px; height: 320px;]/c/portal/getImageAttachment?filename=RadioactivityAnalysis-AmericanumWT.jpg&userId=48754[/img] This time there are more then 20000 events recorded. Note that the waiting times are much shorter than in the background case. We can now compare the histograms of the waiting time between two consecutive events: [img=width: 576px; height: 322px;]/c/portal/getImageAttachment?filename=RadioactivityAnalysisHistogram.jpg&userId=48754[/img] The total number of events are not the same, but it is obvious that the waiting times are much shorter for the Americanum element than for the background (blue). The waiting time distribution is expected to be exponentially distributed, so we can fit  [mcode]distBackground = EstimatedDistribution[ tsBackground[[2 ;; -1, 2]] - tsBackground[[1 ;; -2, 2]], ExponentialDistribution[\[Mu]]][/mcode]which gives [quote]ExponentialDistribution[0.302391][/quote]and  [mcode]distAmericanum = EstimatedDistribution[ tsAmericanum[[2 ;; -1, 2]] - tsAmericanum[[1 ;; -2, 2]], ExponentialDistribution[\[Mu]]][/mcode]which gives [quote]ExponentialDistribution[1.15882][/quote] The mean waiting time for the background is [mcode]Mean[distBackground] (*3.30698*)[/mcode]and for the Americanum element [mcode]Mean[distAmericanum] (*0.862946*)[/mcode]Here is another representation [mcode]Show[{ListLinePlot[ Transpose[{HistogramList[ tsBackground[[2 ;; -1, 2]] - tsBackground[[1 ;; -2, 2]]][[ 1]][[;; -2]], HistogramList[ tsBackground[[2 ;; -1, 2]] - tsBackground[[1 ;; -2, 2]]][[ 2]] // Log // N}], Mesh -> All, AxesLabel -> {"waiting time", "Log number"}, ImageSize -> Large], ListLinePlot[ Transpose[{HistogramList[ tsAmericanum[[2 ;; -1, 2]] - tsAmericanum[[1 ;; -2, 2]]][[ 1]][[;; -2]], HistogramList[ tsAmericanum[[2 ;; -1, 2]] - tsAmericanum[[1 ;; -2, 2]]][[ 2]] // Log // N}], PlotStyle -> Red, Mesh -> All]}][/mcode] [img=width: 576px; height: 335px;]/c/portal/getImageAttachment?filename=RadioactivityAnalysis-Histogram2.jpg&userId=48754[/img] Wolfram Alpha knows a lot of useful stuff about Americanum 241, try:[mcode]== AM 241[/mcode] One little issue with the measurement is that the Americanum element is supposed to have 33000 Bq, i.e. decays per second. Our measurement, corrected for background radiation, shows that there is more or less one additional decay per second. When the measurement was conducted, the red cap at the tip of the Geiger counter was not removed; this filters out the alpha radiation. I read somewhere that only less than 10% of the events come from gamma radiation, even though that seems incorrect given the information on [url=http://en.wikipedia.org/wiki/Americium]wikipedia[/url]. Also the detector was at a distance of about 3 cm from the element. Its opening is about 1cm^2. That might account for another factor of 100, but we would still be much below the at least 33 events per second. I have not really looked into this or done any calculations, but it might be nice to find the missing events. This does not seem to be a problem with the 0.002 Updateinterval, as visual inspection of the time series shows that there are nearly no incidence of two bits being read at the same time from the serial port. The Geiger conter can measure up to 100Hz. The counts per minute of the background radiation are about 20 which is reasonable. (The measurement was made in Aberdeen (UK) where many houses are made from Granite which is slightly radioactive. Inside the hoses Radon is produced which can sometimes yield very high levels of radiation. This particular measurement was not taken in a Granite house.)  If anyone cares about good random numbers, they can use [mcode]tsAmericanum[[All, 1]][/mcode] To extract a string of ones ans zeros, which are "real" random numbers. I attach a file with the sequence of ones and zeros I got from the Americanum experiment. You can also use that to analyse how many times our update interval was too slow so that two digits were transmitted at once. The file can be read with: [mcode]data = Import["~/Desktop/RandomAmericanum.csv"] // Flatten[/mcode] A simple Tally shows that  [mcode]Tally[data] (*{{0, 11779}, {1, 11979}, {11, 65}, {10, 1}}*)[/mcode]Only 66 cases out of about 22000 were double digits. Much about the code can/should be improved. Using an intermediate Arduino might improve the measurements slightly. M. PS: Note that there might be regulations in your country regarding the Americanum element of the smoke detector, e.g. how to dispose of them. Also Sparkfun does not deliver the Geiger Counter to all countries.  Marco Thiel 2014-05-12T21:33:18Z https://community.wolfram.com/groups/-/m/t/23261 I've recently started having fun with Arduino (see [b][url=http://www.arduino.cc/]www.arduino.com[/url][/b] for details).  The memory and processing speed is far below what is necessary to run the Mathematica kernel, but I wonder if an Arduino program might somehow make calls to a Mathematica kernel (running on a network-connected machine) and get results back.  Has anyone done this? David DeBrota 2012-10-19T12:17:10Z https://community.wolfram.com/groups/-/m/t/1026495 Here is something that I do in my lectures regarding the coffee cooling problem. I use just standard Mathematica and a rather simple approach based on Newton's law for cooling. See also a related [System Modeler post][1]. Newton's Law of Cooling ----------------------- When Newton described the cooling for an object, he used the simple assumption that the change of the temperature of an object is proportional to the temperature difference of the environment and the object. ![enter image description here][2] Here Temp(t) is the temperature of the object and TU is the temperature of the environment, e.g. the ambient air. The coefficient $\kappa$ indicates how fast the adaptation to the outside temperature takes place. In Mathematica it looks like this: sols = DSolve[{D[Temp[t], t] == -\[Kappa] (Temp[t] - TU), Temp[0] == T0}, Temp, t] Here we assume that the starting temperature is T0. If we assume the starting temperature to be 80 degrees C and the air temperature to be 20 degrees C, and $\kappa=0.1$ we obtain the following plot. Plot[Temp[t] /. sols /. {\[Kappa] -> 0.1, TU -> 20, T0 -> 80}, {t, 0, 60}, PlotRange -> {All, {0, 100}}, AxesLabel -> {"Time", "Temperature"}, LabelStyle -> Directive[Bold, Medium]] ![enter image description here][3] In fact, if we had data we could determine the value for $\kappa$ from experiments. When do I put the milk in my coffee? ------------------------------------ So here's the question. If I am in a hurry in the morning and need to catch a bus. I love my coffee but do not want to burn my lips. When do I pour the cold milk in? As early on as I can or just before I need to leave the house? We can easily model the adding of milk to some coffee by using the WhenEvent function: sols = NDSolve[{D[Temp[t], t] == -0.1 (Temp[t] - 20), Temp[0] == 80, WhenEvent[t > 1, Temp[t] -> (200. Temp[t] + 50.* 5.)/250.]}, Temp, {t, 0, 30}] it uses a simplified version of the law that governs the mixing of fluids (same calorific capacities). ![enter image description here][4] where Tmix is the temperature of the resulting coffee-milk mix, mc and mm are the mass of the coffee and the milk, and Tc and Tm their respective temperatures. Note that the model is not quite correct in the sense that it does not take into consideration that the mass of the content of the mug has changed after the milk is added. First we put the milk in right at the beginning: sols = NDSolve[{D[Temp[t], t] == -0.1 (Temp[t] - 20), Temp[0] == 80, WhenEvent[t > 1, Temp[t] -> (200. Temp[t] + 50.* 5.)/250.]}, Temp, {t, 0, 30}] Here's the graph. Plot[Temp[t] /. sols, {t, 0, 30}, PlotRange -> All, AxesLabel -> {"Time", "Temperature"}, LabelStyle -> Directive[Bold, Medium]] ![enter image description here][5] Next we wait for 10 minutes and then pour the milk in: sols2 = NDSolve[{D[Temp[t], t] == -0.1 (Temp[t] - 20), Temp[0] == 80, WhenEvent[t > 10, Temp[t] -> (200.* Temp[t] + 50.* 5.)/250.]}, Temp, {t, 0, 30}] Here's the plot: Plot[Temp[t] /. sols2, {t, 0, 30}, PlotRange -> All, AxesLabel -> {"Time", "Temperature"}, LabelStyle -> Directive[Bold, Medium]] ![enter image description here][6] If we plot both together we get this: Show[Plot[Temp[t] /. sols, {t, 0, 30}, PlotRange -> All], Plot[Temp[t] /. sols2, {t, 0, 30}, PlotRange -> All], AxesLabel -> {"Time", "Temperature"}, LabelStyle -> Directive[Bold, Medium]] ![enter image description here][7] Clearly, I should put my milk in as late as possible. Well, that's the model. Getting data for our model -------------------------- Let's get some data with an Arduino and a simple temperature sensor. We use a standard Arduino Uno and wire it like so: ![enter image description here][8] I use a standard Arduino and a [Dallas Temperature Sensor][9]. We then need to upload an Arduino C-program, which is called Sketch, to the microcontroller. #include <OneWire.h> #include <DallasTemperature.h> // Data wire is plugged into pin 2 on the Arduino #define ONE_WIRE_BUS 2 // Setup a oneWire instance to communicate with any OneWire devices // (not just Maxim/Dallas temperature ICs) OneWire oneWire(ONE_WIRE_BUS); // Pass our oneWire reference to Dallas Temperature. DallasTemperature sensors(&oneWire); void setup(void) { // start serial port Serial.begin(9600); // Start up the library sensors.begin(); } void loop(void) { sensors.requestTemperatures(); // Send the command to get temperatures Serial.print(sensors.getTempCByIndex(0),4); Serial.print(","); } The upload is done via the Arduino IDE. (I could do it directly from within Mathematica.) ![enter image description here][10] The Arduino is connected via a serial (i.e. USB) cable to the computer. Mathematica can connect to the serial port like so (on a Mac, slightly different on a Windows machine): myDSTemperature = DeviceOpen["Serial", {Quiet[FileNames["tty.usb*", {"/dev"}, Infinity]][[1]], "BaudRate" -> 9600}] We can then run a ScheduledTask every second: s = {}; tZero = AbsoluteTime[]; DeviceReadBuffer[myDSTemperature]; RunScheduledTask[ AppendTo[s, {AbsoluteTime[] - tZero, ToExpression@(StringSplit[FromCharacterCode@DeviceReadBuffer[myDSTemperature], ","][[-1]])}], 1] We can then display the result dynamically: Dynamic[ListLinePlot[s, PlotRange -> {All, {20, 40}}]] After that you might want to stop the Scheduled task and close the connection: RemoveScheduledTask /@ ScheduledTasks[]; DeviceClose[myDSTemperature] I have attached the measurements I obtained for my experiment. You can load and display it like this: ClearAll["Global`*"] data = Import["~/Desktop/temperaturedata_CoffeMilkGood.csv"]; dataclean = Table[Join[{data[[k]][[1 ;; 6]]}, data[[k]][[7 ;; 9]]], {k, 1, Length[data]}]; data2plotearlymilk = Select[Transpose[{dataclean[[All, 1]], dataclean[[All, 3]]/1000.}], #[[2]] > 0 &]; data2plotlatemilk = Select[Transpose[{dataclean[[All, 1]], dataclean[[All, 2]]/1000.}], #[[2]] > 0 &]; DateListPlot[{data2plotearlymilk, data2plotlatemilk}, PlotRange -> {All, {0, 100}}, Joined -> True, FrameLabel -> {"Time", "Temperature"}, LabelStyle -> Directive[Bold, Medium]] ![enter image description here][11] There is clearly one measurement error at the blue curve, but it does appear to show that there is a better chance of not burning my lips if I put the milk in as late as I can. Note that I have assumed that the air temperature does not change. In fact, I also measured the air temperature when I did the experiment - it is constant as expected. As I said, I know that this is not really addressing the original question, but when I teach mathematical modelling, I always like showing the students that is quite relevant to compare the models to data. Cheers, Marco [1]: http://community.wolfram.com/groups/-/m/t/1021383 [2]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.21.22.png&userId=48754 [3]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.29.35.png&userId=48754 [4]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.38.21.png&userId=48754 [5]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.41.25.png&userId=48754 [6]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.42.59.png&userId=48754 [7]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.44.18.png&userId=48754 [8]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.31.12.png&userId=48754 [9]: https://www.amazon.co.uk/gp/product/B00CHEZ250/ [10]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.34.45.png&userId=48754 [11]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2017-02-28at15.51.11.png&userId=48754 Marco Thiel 2017-03-07T00:34:37Z https://community.wolfram.com/groups/-/m/t/615905 **Connecting ROS to the Wolfram Language** ====================================== *Or Controlling a Parrot ArDrone 2.0 from Mathematica* ---------------------------------------------------- ![enter image description here][1] ---------- Foreword -------- During this summer, between the end of my high school education and the beginning of my undergraduate studies, I had the opportunity to participate in the Wolfram Mentorship program where I worked on a project called "Connecting ROS to the Wolfram Language". [ROS][2], which is an abbreviation for "Robot Operating System", is a software available for Linux which acts as a 'conductor' between different electronic components of one or more robots (such as the engine, the cameras...) such that the components and the controller (a computer for example) can communicate together. A good introduction to ROS can be found [here][3] and in depth tutorials are available [there][4]. The aim of this project was to implement a connection to ROS from the Wolfram Language, i.e. to be able to collect and interpret data from the robots controlled by ROS in Mathematica as well as to control ROS and the robots from Mathematica and to test the results using a Parrot ArDrone 2.0. This post, which marks the end of the project, describes the different steps I went through to complete this project. It assumes prior knowledge of ROS (and the [ardrone autonomy package][5]) as well as basic Linux and Mathematica. It is divided into two parts: 1. 'collecting and interpreting data' in Mathematica 2. 'controlling ROS and supported Robots' from Mathematica, These are independent and throughout the first part code developed is illustrated using turtlesim (a simulator of a turtle - used in ROS tutorials) and throughout the second part, the examples refer to the Parrot ArDrone 2.0. ---------- PART 1: COLLECTING & INTERPRETING DATA -------------------------------------- Extracting and Understanding Data from ROS ------------------------------------------ After installing ROS and getting familiar with the environment, the first step is to figure out how to extract data from it, or to be more precise, how to log all the messages published over one or more topic in a file which can be retrieved by the user. Although, there is a tool called a rosbag which records the selected ROS topics and store them in a .bag file, it turns out that I only managed to open these files in ROS so a different procedure was used. It consists of echoing the messages published on selected topics (using the command rostopic echo) to a file of the chosen format (since messages are just simple text files the format used will be .txt). This can simply be done by executing the following command in the Linux terminal before sending messages over the topic(s) (once ROS is installed and started): rostopic echo [topic] > [file].txt For example, if we were going to extract the velocity commands sent to the turtle to a file called rosdata.txt, the command would be: rostopic echo /turtle/cmd_vel > rosdata.txt And opening the text file (once the ROS session is ended) would return a sequence of messages looking like the one below (the values of x,y,z might change): linear x: 1.0 y: 0.0 z: 0.0 angular x: 0.0 y: 0.0 z: 1.0 _ _ _ Now, In order to 'use' the data, it is necessary to understand the structure of the text file. It can be represented by the 'fomula' below : Header_1 (some indication about variables displayed beneath) Variable_1: value1 (a variable name followed by its value) .... Varable_n: value n (a variable name followed by its value) .... Header_n (some indication about variables displayed beneath) Variable_1: value1 (a variable name followed by its value) .... Varable_n: value n (a variable name followed by its value) _ _ _ (end of message) So, going back to the turtlesim example: - linear x represents the linear velocity of the turtle (in m/s), - angular z represents the angular velocity of the turtle in rad/s (its bearing being the sum of the angular displacements). - The other variables are always 0 as the turtle moves in a 2D plane. Note: the meaning of a variable in a message might not always be obvious at first sight (due to ambiguous variable name such as x,y,z for instance) however, by observing the values of the variables against the action of the robots (the trajectory it takes in our case), this meaning can be quite easily retrieved. Importing the Data into Mathematica ----------------------------------- Now that is possible to retrieve and understand messages published over a ROS topic the next step is to import those messages in Mathematica. In order to do this, a function, taking the path of the text file containing the messages as an argument and returning the messages in a list created; as displayed below: MessageImport[filepath_]:= Module[ {stream=OpenRead[filepath],character,rules= {}}, character=Read[stream,String]; Reap[ While[character=!=EndOfFile, If[character=== "---", Sow[Flatten[rules]];rules= {}, AppendTo[rules, StringCases[character, {var:(WordCharacter..)~~":"~~Whitespace~~value:NumberString:>(var->ToExpression[value]), var:(WordCharacter..)~~":"~~Whitespace:>("Head"->var)}]]]; character=Read[stream,String]]; Close[stream];][[2,1]]]; And, it is then possible to represent this in a dataset like so: Dataset[ Association[#]&/@ Partition[ Flatten[ MessageImport[filepath_]],4]] Hence, returning to the turtlesim example, if rosdata.txt is the file where the velocity command messages are published, the code below: Dataset[ Association[#] & /@ Partition[ Flatten[ MessageImport["rosdata.txt"]], 4]] would return something of the form: ![enter image description here][6] Interpreting the Data --------------------- Having imported the Data into Mathematica it can now be interpreted using the Wolfram Language. For example, in the case of a topic where the messages published contain linear and angular velocities like the one described above, the path of the robot can be retrieved using the following code (using the function AnglePath): Graphics[Line[AnglePath[Values[MessageImport[filepath_][[All,{2,8}]]]]]] Therefore,considering the turtlesim example, if the path of the turtle was: ![enter image description here][7] The following code: Graphics[Line[AnglePath[Values[MessageImport["rosdata.txt"][[All,{2,8}]]]]]] would return: ![enter image description here][8] which is the same as the actual path taken by the turtle. ---------- PART 2: CONTROLING ROS AND SUPPORTED ROBOTS ------------------------------------------- Sending Commands to ROS from Mathematica ---------------------------------------- Yet another thing to consider is how to send ROS commands from Mathematica in order to be able to directly operate ROS and record ROS data from a Mathematica notebook. One possible way to do so would be to use the Run command, however, it is necessary to source ROS commands before executing them and I did not manage to do so with the Run command. So, another method to execute ROS commands from Mathematica is to create an empty shell script (using the chmod command in the Linux terminal) and then one can write the desired commands in the script and execute it from Mathematica, thanks to the function below (which takes the desired commands as an argument) : RosCommand[Command_]:= WaitNext[ ParallelSubmit/@ Unevaluated[{ {WriteString[ OpenWrite["script"], "bash -c \"source /opt/ros/indigo/setup.bash && source ~/catkin_ws/devel/setup.bash && ",Command,"\""],Close["script"], SetDirectory["/"], SetEnvironment["LD_LIBRARY_PATH"->""], RunProcess["script","StandardOutput"], SetEnvironment["LD_LIBRARY_PATH"->FileNameJoin[{$InstallationDirectory,"SystemFiles","Libraries",$SystemID}]], SetDirectory["your working directory"]}, Pause[5]}]]; Note: a second kernel is used in that code in order to kill the process running in the first one as some commands executed by the ROS command function would evaluate indefinitely. Hence, to start the ROS master, the command would be : RosCommand[rosstart] Publishing messages from Mathematica ------------------------------------ Finally, another thing to implement in order to be able to perform most of ROS's basic features from Mathematica is to be able to publish messages on topics. In some cases this can be done by using the ROS command $rostopic publish through the RosCommand function described in the previous section. This method works fine however there is quite a considerable latency between the moment command is evaluated and the moment the command is actually published (about 1-2 seconds). Hence, this way only works for topics where messages have to be published at a rate lower than 0.5 Hz, for example the take off and land commands for the drone, as shown below: Takeoff: RosCommand["rostopic pub ardrone/takeoff std_msgs/Empty"] Landing: RosCommand["rostopic pub ardrone/land std_msgs/Empty"] For topics where the rate for which the messages have to be published at a rate greater than 0.5 Hz, a publisher ROS node (a 'Mathematica' node), intaking the arguments from Mathematica should be created. This can be written in C++ and the arguments from Mathematica can be transferred by simple file I/O code; i.e. this process would have the following structure: - Mathematica Notebook: - Some functions would assign a value to the desired message variables (controller part) - Some code would save the variable values to a text file at a chosen rate - C++ code: - Some code declaring the Publisher Node - Some code importing the variable values from the text file - Some code publishing these values at the chosen rate Note: the instructions to build the node are available [here][9]. Hence, to send velocity commands to the ArDrone from Mathematica, the Mathematica Notebook could be : CONTROL PART: Turn right: {p = {1, 0, 0}; Pause[1]; p = {0, 0, 0}} Move forwards: {p = {0, 0.2, 0}, Pause[1], p = {0, 0, 0}} Move Up: {p = {0, 0, 0.1}, Pause[1], p = {0, 0, 0}} Move Down: {p = {0, 0, -0.1}, Pause[1], p = {0, 0, 0}} VARIABLE OUTPUT PART: Dynamic[ Refresh[ StringJoin["b ", Flatten[{ If[Round[p[[1]],0.1]>=0, PadRight[Characters[ToString[Round[p[[1]],0.1]]],3,"0"], PadRight[Characters[ToString[Round[p[[1]],0.1]]],4,"0"]], " ", If[Round[p[[2]],0.1]>=0, PadRight[Characters[ToString[Round[p[[2]],0.1]]],3,"0"], PadRight[Characters[ToString[Round[p[[2]],0.1]]],4,"0"]]," ", If[Round[p[[3]],0.1]>=0, PadRight[Characters[ToString[Round[p[[3]],0.1]]],3,"0"], PadRight[Characters[ToString[Round[p[[3]],0.1]]],4,"0"]] }]," e"]>>"file.txt" ,UpdateInterval->1]] where p={angluar_z, linear_x, linear_z} and: - angular_z represents the angular velocity of the drone in the xy plane (in rad/s) (its bearing being the sum of the angular displacements), - linear_x represents the linear velocity of the drone in the xy plane (in m/s), - linear_z represents the velocity of the drone along the z axis (in m/s). Moreover, the C++ code could look like: #include "ros/ros.h" #include "geometry_msgs/Twist.h" #include <boost/lexical_cast.hpp> #include <iostream> #include <string> #include <fstream> #include <stdlib.h> using namespace std; int main(int argc, char **argv) { ros::init(argc, argv, "mathematica"); ros::NodeHandle n; ros::Publisher chatter_pub = n.advertise<geometry_msgs::Twist>("/cmd_vel", 1000); ros::Rate loop_rate(1.0); int count = 0; while (ros::ok()) { //start ifstream infile( "file.txt" ); double nb; double nb2; double nb3; string b; string e; (infile >> b >> nb >> nb2 >> nb3 >> e); //end geometry_msgs::Twist vel_msg; vel_msg.linear.x = nb2; vel_msg.linear.y =0.0; vel_msg.linear.z = nb3; vel_msg.angular.x =0.0; vel_msg.angular.y =0.0; vel_msg.angular.z = nb; ROS_INFO("[Random Walk] linear.x = %.2f, angular.z=%.2f\n", vel_msg.linear.x, vel_msg.angular.z); chatter_pub.publish(vel_msg); ros::spinOnce(); loop_rate.sleep(); ++count; } return 0; } ---------- Conclusion ---------- Throughout the Mentorship program, I developed functions enabling me to fully interact with ROS and the robot(s) it is controlling from a Mathematica notebook. Owning a Parrot ArDrone myself, which is a device supported by ROS, I tested this in real conditions and the result can be seen below: ![enter image description here][10] This is only a GIF, the full video is available [here][11]. All, in all, I have thoroughly enjoyed working on this project and would love to hear your feedback. I see it as a starting point towards using the many abilities of the Wolfram Language in order to improve the capabilities of ROS supported robots: I can already imagine myself using Mathematica to create an autopilot for my drone ! Finally, I would also like to thanks Todd Rowland, Alison Kimball and Wolfram Research for the help and support provided throughout the mentorship program. Loris Gliner [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=fig0.png&userId=553216 [2]: http://www.ros.org/ [3]: http://robohub.org/ros-101-intro-to-the-robot-operating-system/ [4]: http://wiki.ros.org/ [5]: http://wiki.ros.org/ardrone_autonomy [6]: http://community.wolfram.com//c/portal/getImageAttachment?filename=fig1.PNG&userId=553216 [7]: http://community.wolfram.com//c/portal/getImageAttachment?filename=fig2.JPG&userId=553216 [8]: http://community.wolfram.com//c/portal/getImageAttachment?filename=fig3.png&userId=553216 [9]: http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber%28c++%29 [10]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ardronegif.gif&userId=553216 [11]: https://www.youtube.com/watch?v=zD8yjOCWhJQ Loris Gliner 2015-11-17T17:57:08Z https://community.wolfram.com/groups/-/m/t/1057588 My project, Parallel Mathematica Environment on the RaspberryPi using OOP, is a sample application of **Object Oriented Programming for the Mathematica** cluster computing, implemented with a Mac and three RaspberryPi Zero connected with a USB hub and three USB cables. Basic idea is to deploy a constructed instance image to calculating servers (RaspberryPi) and send messages to the instance. [OOP on the Mathematica is already developed and shown][1] in this community, and further detail is shown on [slidesshare][2] titled of "OOP for Mathematica." ![enter image description here][3] ---------- Preparing for RaspberryPi Zero is as follows using SSH connection from a Mac, - naming each Zero as raspberypi,raspberrypi1,raspberrypi2,... - set the server program "init" to each RaspberryPi, init is, $ cat init While[True, Run[“nc -l 8000>input”]; temp=ReleaseHold[<<input]; temp >>output; Run[“nc your-mac-hostname.local 8002<output”] ] where, socket numbers must be identical. - Run Mathematica manually, and wait the booting Mathematica up. $ wolfram <init& Checking each RaspberryPi is useful as, $ nc -l 8002 >output|nc raspberrypi.local 8000 <<EOF > 10! > EOF $ cat output 3628800 ---------- Cluster controller program on a Mac is, - set directory SetDirectory[NotebookDirectory[]]; - setup socket communication process com1="nc -l 8002 >output1 |nc raspberrypi.local 8000 <input1"; com2="nc -l 9002 >output2 |nc raspberrypi1.local 9000 <input2"; com3="nc -l 9502 >output3 |nc raspberrypi2.local 9500 <input3"; - set object property obj={ <|"name"->node1,"comm"->com1,"in"->"input1","out"->"output1","p"->{2000,3500}|>, <|"name"->node2,"comm"->com2,"in"->"input2","out"->"output2","p"->{3501,4000}|>, <|"name"->node3,"comm"->com3,"in"->"input3","out"->"output3","p"->{4000,4500}|>}; - define calculation server class, where is a sample Mersenne prime number calculation new[nam_]:=Module[{ps,pe}, mersenneQ[n_]:=PrimeQ[2^n-1]; setv[nam[{s_,e_}]]^:={ps,pe}={s,e}; calc[nam]^:=Select[Range[ps,pe],mersenneQ] ]; - construct instances Map[new[#name]&,obj]; - deploy instances to calculation servers Map[Save[#in,#name]&,obj]; Map[Run[#comm]&,obj]; - send message to each instance Map[Put[Hold@setv[#name[#p]],#in]&,obj]; Map[Run[#comm]&,obj]; - start calculation Map[Put[Hold@calc[#name],#in]&,obj]; proc=Map[StartProcess[{$SystemShell,"-c",#comm}]&,obj] - wait for the process termination (mannualy in this sample code) Map[ProcessStatus[#]&,proc] {Finished,Finished,Finished} - gather the results Map[FilePrint[#out]&,obj]; {2203, 2281, 3217} {} {4253, 4423} [1]: http://community.wolfram.com/groups/-/m/t/897081?p_p_auth=o5qxZhNR [2]: https://www.slideshare.net/kobayashikorio/oop-for-mathematica [3]: http://community.wolfram.com//c/portal/getImageAttachment?filename=2017-04-10.jpg&userId=897049 Hirokazu Kobayashi 2017-04-10T01:15:22Z https://community.wolfram.com/groups/-/m/t/454226 Recently Stephen Wolfram announced the [Wolfram Data Drop][1], which is a great new tool to upload any type of data from any type of device. In this post, I will show how you can use the Data Drop when building your own weather station using some basic hardware and a few lines of code. Once completed, your device will take temperature measurements every second for 60 seconds, and upload their average value to the Wolfram DataDrop every minute. This will give you 60 data points per hour and 1,440 data points per day. With this data you can then use the Wolfram Programming Cloud to understand how the temperature changes over time: You can find out the exact times in a given day when the temperature was the highest or lowest, and when the temperature changed the fastest, and maybe even use the data to make predictions for the future! Can you beat your local weather station and make a prediction that is better? ![enter image description here][2] How to build your weather station --------------------------------- For this experiment you will need an [Arduino Yun][3] (or an equivalent Arduino that has wireless capability), a [TMP36 temperature sensor][4] and a breadboard and jumper wires. Here is the hardware diagram. Connect the 5V pin to the left pin of the TMP36 sensor, connect the GND pin to the right pin of the TMP36, and the A0 pin to the middle TMP36 pin. ![enter image description here][5] Once everything is connected and powered up, the TMP36 sensor will send a voltage to the A0 pin. This voltage increases when the temperature goes up and it decreases when the temperature goes down. So we can use the voltage reading and interpret it as a temperature. Luckily in this experiment we only needed three jumper cables, so hopefully you did not end up looking like this poor man: ![enter image description here][6] Programming the Arduino ------------------------- Now we are ready to write the Arduino code which is going to upload the recorded temperature data to the Wolfram Cloud. Make sure your Arduino Yun is configured to connect to the internet (http://arduino.cc/en/Guide/ArduinoYun#toc13). Then using the Arduino application, upload the following sketch onto your Arduino after you replace the text 'YOUR_BIN_ID' with the 'Short ID' of a Databin that you created yourself: CreateDatabin[] ![enter image description here][7] To follow along with the code, here is what it does: The process 'p' variable is used for calling a tool called 'curl' which is a way to make http requests with your Arduino. In our case we call a specific 'data drop' url, which lets you upload small bits of temperature data easily (https://datadrop.wolframcloud.com/api/v1.0/Add). In the loop() section of the code you can see how the variable 'val' is reading from the analog pin (A0) and how it is then converted from a raw reading to a 'temperature' variable. This temperature is then added to an 'average' variable exactly 60 times, but on the 60th time, the code will execute the block of the if statement. This code block runs the data upload code to upload the average of the 60 measurements and it also resets all the counters, so that everything will start over again. Finally, at the end, is a 1000 millisecond delay which will (approximately) space out your recorded temperatures by one second. <pre> #include <Bridge.h> Process p; int val,count; float voltage,temperature,average; void setup() { count=0; average=0; Bridge.begin(); Serial.begin(9600); } void loop() { val = analogRead(0); voltage = val * 5.0; voltage = voltage/1024.0; temperature = (voltage-0.5)*100; average += temperature; count++; if( count>59 ) { p.begin("/usr/bin/curl"); p.addParameter("--insecure"); p.addParameter("--location"); p.addParameter("https://datadrop.wolframcloud.com/api/v1.0/Add?bin=YOUR_BIN_ID&temperature="+String(average/60)); p.run(); while(p.available()>0) { char c = p.read(); Serial.print(c); } Serial.println(); Serial.flush(); count = 0; average = 0; } delay(1000); } </pre> To test that everything worked, you can open the Arduino serial monitor. If successful, you will see these messages like the one below appear every minute or so: <|"Message" -> "The data was successfully added.", "Bin" -> "DD7051e03ace9-a194-44c1-9864-8fcef8ea9af3", "Data" -> <|"temperature" -> "34"|>, "Timestamp" -> {2015, 2, 9, 16, 18, 39.99526`8.354583502904967}, "Information" -> {"EntryCount" -> 1, "LatestTimestamp" -> 3632487520, "Size" -> 288}|> Now you can put your device in a weather resistant container (I used a Hefty bag) and place it outside in a location that is shaded for most of the day (like a porch): ![enter image description here][8] Analysis of the temperature data ---------------------- Now we're ready to do some interesting analysis of your temperature data! It's best to collect at least one full day of data before analyzing it, but the code below should work for shorter time periods as well. First we need to get the data from the databin we used to upload the temperature data. The arduino sketch uses 'temperature' as the url parameter for the temperature, so we will need to use the same thing here to retrieve it. In this example, my databin has collected data for about 20 days (for your experiment, replace the text 'YOUR_BIN_ID' with the bin id shown in the output from CreateDatabin[] above): bin = Databin["YOUR_BIN_ID"]; data = bin["Data"]; temperature = data["temperature"] ![enter image description here][9] Now we will need to transform the temperature event series in a few more steps: First, shift the series to account for the proper time zone (CST). This is done with the TimeSeriesShift command. Next, calibrate the temperatures so they match more closely official NOAA measurements for a nearby official weather station. In my case I used official an NOAA weather station (KCMI) to calibrate my $2 TMP36 temperature sensor with the undoubtably much more expensive and precise offcial sensor data. Calibration is an important step and in this case I had to correct my data by about 5 degrees Celsius to match the official data. Another good way to calibrate your TMP36 sensor is to place it into a cup with ice water (exactly 0 degrees Celsius) and a cup with boiling water (exactly 100 degrees Celsius). Next, define the time window of interest. In my case the starting point of reliable data was on DateObject[{2015,1,22,21,0,0}] (January 22 at 9PM). You will need to change this to a date which is a good starting point for your data. Finally, resample the data to evenly spaced periods of 15 minutes. You will quickly notice that recording data every minute will give you a massive amount of data points and sampling it back to 15 minute intervals will still give you enough data to work with for plots that show multiple days of data. Here is all the code we just discussed above: temperature = EventSeries[Cases[First[temperature["Paths"]], {_Real, _Real}]]; temperature = TimeSeriesShift[temperature, Quantity[-6, "Hours"]]; temperature = TimeSeriesMap[# - 5 &, temperature]; temperature = TimeSeriesWindow[ temperature, {DateObject[{2015, 1, 22, 21, 0, 0}], Now}]; temperature = TimeSeriesResample[temperature, Quantity[0.25, "Hours"], ResamplingMethod -> {"Interpolation", InterpolationOrder -> 1}]; Now at this point you can do a quick check that your temperature data is looking OK: DateListPlot[temperature, GridLines -> Automatic] ![enter image description here][10] But we can make this a lot more useful and interesting. Let's write a function which will collect a specific point of interest for each day of data, for example the Min and Max of this data: TimeSeriesFilter[series_, func_] := Module[{startdate, enddate, daterange}, startdate = First[series["Dates"]] /. {DateObject[{y_, m_, d_}, TimeObject[{_, _, _}]] :> DateObject[{y, m, d}, TimeObject[{0, 0, 0}]]}; enddate = Last[series[ "Dates"]] /. {DateObject[{y_, m_, d_}, TimeObject[{_, _, _}]] :> DateObject[{y, m, d}, TimeObject[{0, 0, 0}]]}; daterange = DateRange[startdate, enddate, Quantity[1, "Days"]]; EventSeries[ Table[window = TimeSeriesWindow[ series, {date, DatePlus[date, Quantity[1, "Days"]]}]; path = window["Path"]; First[Select[path, Last[#] == func[window] &]], {date, daterange}] ] ] This function above simply generates a new EventSeries from the given one and collects the data points that satisfy a particular function for a given day. First let's create a new EventSeries which contains all the daily minimum temperatures: minseries = TimeSeriesFilter[temperature, Min] ![enter image description here][11] maxseries = TimeSeriesFilter[temperature, Max] ![enter image description here][12] And now we can plot the temperature data (purple) with the daily minimum temperatures (blue dots) and maximum temperatures (red dots): DateListPlot[{temperature, minseries, maxseries}, GridLines -> Automatic, Filling -> Axis, PlotLabel -> Style["Temperature (\[Degree]C) in Savoy, Illinois", 16, FontColor -> White], ImageSize -> Large, Joined -> {True, False, False}, Background -> Black, FrameStyle -> White, ImagePadding -> 30, PlotStyle -> {Purple, {Blue, AbsolutePointSize[6]}, {Red, AbsolutePointSize[6]}}] ![enter image description here][13] Conclusion ------------- And that is it for this experiment! You now have a working weather station, and a dataset which is easy to analyze: By modifying the given code you can visualize daily averages or weekly or monthly averages. Or you can try to make predictions for tomorrow's weather based on patterns you have observed in the past (and perhaps combine this data with additional weather measurements like pressure and humidity data). [1]: https://datadrop.wolframcloud.com/ [2]: /c/portal/getImageAttachment?filename=one.png&userId=22112 [3]: http://arduino.cc/en/Main/ArduinoBoardYun?from=Products.ArduinoYUN [4]: https://www.sparkfun.com/products/10988 [5]: /c/portal/getImageAttachment?filename=two.png&userId=22112 [6]: /c/portal/getImageAttachment?filename=three.png&userId=22112 [7]: /c/portal/getImageAttachment?filename=four.png&userId=22112 [8]: /c/portal/getImageAttachment?filename=five.png&userId=22112 [9]: /c/portal/getImageAttachment?filename=six.png&userId=22112 [10]: /c/portal/getImageAttachment?filename=seven.png&userId=22112 [11]: /c/portal/getImageAttachment?filename=eight.png&userId=22112 [12]: /c/portal/getImageAttachment?filename=nine.png&userId=22112 [13]: /c/portal/getImageAttachment?filename=ten.png&userId=22112 Arnoud Buzing 2015-03-06T22:05:52Z https://community.wolfram.com/groups/-/m/t/992466 This project was part of a Wolfram Mentorship Program. The classification of human motions based on patterns and physical data is of great importance in developing areas such as robotics. Also, a function that recognizes a specific human motion can be an important addition to artificial intelligence and physiological monitoring systems. This project is about acquiring, curating and analyzing experimental data from certain actions such as walking, running and climbing stairs. The data taken with the help of an accelerometer needs to be turned into an acceptable input for the Classify function. Finally, the function can be updated with more data and classes to make it more efficient and whole. **Algorithms and procedures** The data for this project was acquired by programming an Arduino UNO microprocessor with a Raspberry Pi computer, using Wolfram Language. An accelerometer connected to the Arduino sent measurements each time it was called upon, and Mathematica in the Raspberry Pi collected and uploaded the data. The raw data had to be processed for it to be a good input for the classify function. First, it was transformed into an spectrogram (to analyze the frequency domain of the data). Then, the spectrogram's image was put through the IFData function which filters out some of the noise, and finally the images were converted into numerical data with the UpToMeasurements function (main function: ComponentMeasurements). This collection numerical data was put in a classify function under six different classes (standing, walking, running, jumping and waving). *The IFData function and the UpToMeasurements functions were sent to me by Todd Rowland during the Mentorship. Both functions will be shown at the end of this post. **Example visualization** The following ListLinePlot is an extract from the jumping data ![Example data][1] Next, the data from the plot above is turned into a spectrogram by the function Spectrogram, i.e.: spectrogramImage = Spectrogram[jumpingData, SampleRate -> 10, FrameTicks -> None, Frame -> False, Ticks -> None, FrameLabel -> None] ![Example jumping data spectrogram][2] Finally, all the spectrogram images are used as input for the UpToMeasurements function, along with some properties for the ComponentMeasurements function: i.e: numericalData = N@Flatten[ UpToMeasurements[ spectrogramImage, {"EnclosingComponentCount", "Max", "MaxIntensity", "TotalIntensity", "StandardDeviationIntensity", "ConvexCoverage", "Total", "Skew", "FilledCircularity", "MaxCentroidDistance", "ExteriorNeighborCount", "Area", "MinCentroidDistance", "FilledCount", "MeanIntensity", "StandardDeviation", "Energy", "Count", "MeanCentroidDistance"}, 1]] Which outputs a list of real numbers, one for each of the properties: {0., 1., 1., 1., 1., 19294.9, 0.222164, 0.985741, 31011.8, 15212.5, \ 9624.42, -0.0596506, 0.724527, 190.534, 0., 42584.5, 0.364667, \ 42584., 0.453101, 0.315209, 0.232859, 0.169549, 0.00909654, 42584., \ 98.7136} These numbers are grouped in a nested list which contains data for all 5 human motions. All the data is lastly classified in a classifier using the Classify function. After several combinations of both properties and data sets, I was able to produce classifier functions with an accuracy of 91%, and a total size of 269kb. ------------------------------------------------------------ **Attempt on building a classify function using image processing** On the other hand, the image processing capabilities of Mathematica lets us extract data from images, hence it should be possible to create a classifier which recognizes the moving patterns in the frames of a video. First, I had to take the noise out of every image, this proved to be troublesome, since the background can vary greatly between video samples. Then, I binarized the image in order to isolate the moving particles in each frame, and extract their position with ImageData. Lastly, a data set can be formed from all the analyzed frames; this data can essentially be used in the same way as the accelerometer's, but the classifier was unsuccessful in separating the samples accurately. This was mainly because the accelerometer's data is taken at a constant rate and very precisely, whereas the images depend on the camera's frame rate, and many other external factors. This is what made the data different enough to fail being classified with accuracy. Furthermore, if a big dataset is made from videos of people performing certain actions, the data processing can follow similar steps as the ones explained in this report. Thus producing a similar classifier function. This can further increase the functions accuracy, but the process needs an algorithm that can effectively trace the path of "a particle" that moves through each of the frames of the video, and extract precise velocity data from said movement. ------------------------------------------------------------ Conclusively, the classify function is working very well with the data provided, its accuracy is about 91% for the SupportVectorMachine method. This is a very good result for the human motion classifier. The next step is to add more classes to the function, and test the classifier with data acquired from different sources, such as another accelerometer and various videos of human motion footage. ----------------------------------------- **Code:** - UpToMeasurements function UpToMeasurements[image_,property_,n_]:=MaximalBy[ComponentMeasurements[image,"Count"],Last,UpTo[n]][[All,1]]/.ComponentMeasurements[image,property] *Note: This function simplifies the exploration of properties to input in ComponentMeasurements, also, it outputs a usable list of numerical data retrieved from a given group of images. - IFData function: imagefunctions=<|1-> (EntropyFilter[#,3]&), 2-> (EdgeDetect[EntropyFilter[#,3]]&), 3->Identity, 4-> (ImageAlign[reference110,#]&), 5-> (ImageHistogram[#,FrameTicks->None,Frame->False,FrameLabel->None,Ticks->None]&), 6-> (ImageApply[#^.6&,#]&), 7-> (Colorize[MorphologicalComponents[#]]&), 8-> (HighlightImage[#,ImageCorners[#,1,.001,5]]&), 9-> (HighlightImage[#,Graphics[Disk[{200,200},200]]]&), 10-> ImageRotate, 11-> (ImageRotate[#,45Degree]&), 12->(ImageTransformation[#,Sqrt]&), 13->(ImageTransformation[#,Function[p,With[{C=150.,R=35.},{p[[1]]+(R*Cos[(p[[1]]-C)*360*2/R]/6),p[[2]]}]]]&), 14->( Dilation[#,DiskMatrix[4]]&), 15->( ImageSubtract[Dilation[#,1],#]&), 16-> (Erosion[#,DiskMatrix[4]]&), 17-> (Opening[#,DiskMatrix[4]]&), 18->(Closing[#,DiskMatrix[4]]&), 19->DistanceTransform, 20-> InverseDistanceTransform, 21-> (HitMissTransform[#,{{1,-1},{-1,-1}}]&), 22->(TopHatTransform[#,5]&), 23->(BottomHatTransform[#,5]&), 24-> (MorphologicalTransform[Binarize[#],Max]&), 25-> (MorphologicalTransform[Binarize[#],"EndPoints"]&), 26->MorphologicalGraph, 27->SkeletonTransform, 28->Thinning, 29->Pruning, 30-> MorphologicalBinarize, 31-> (ImageAdjust[DerivativeFilter[#,{1,1}]]&), 32-> (GradientFilter[#,1]&), 33-> MorphologicalPerimeter, 34-> Radon |>; reference110=BlockRandom[SeedRandom["110"];Image[CellularAutomaton[110,RandomInteger[1,400],400]]]; IFData[n_Integer]:=Lookup[imagefunctions,n,Identity] IFData["Count"]:=Length[imagefunctions] IFData[All]:=imagefunctions *Note: This function groups together several image filtering fuctions; it was used to simplify the exploration of functions to be used in the classifier. **This function was written by the the Wolfram team, but was slightly modified for this project. - propertyVector function (this function automatically evaluates all the prior necessary code needed to create the classify functions): propertyVector[property_]:={walkingvector=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@walk); jumpingvector=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@jump); standingvector=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@stand); runningvector=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@run); wavingvector=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@wave); stairsvector=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@stairs); walkingvectortest=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@testwalk); jumpingvectortest=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@testjump); standingvectortest=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@teststand); runningvectortest=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@testrun); wavingvectortest=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@testwave); stairsvectortest=N@Flatten[UpToMeasurements[#,property,1]]&/@IFData[6]/@(Spectrogram[#,SampleRate->10,FrameTicks->None,Frame->False,Ticks->None,FrameLabel->None]&/@teststairs);} Training:=trainingSet=<|"walking"->walkingvector,"running"->runningvector, "standing"-> standingvector, "jumping"-> jumpingvector, "waving"-> wavingvector, "stairs"-> stairsvector|>; Test:=testSet=<|"walking"->walkingvectortest,"running"->runningvectortest, "standing"-> standingvectortest, "jumping"-> jumpingvectortest, "waving"-> wavingvectortest, "stairs"-> stairsvectortest|>; - Example code for the acceleration data acquisition from image processing: images=Import["$path"] motionData= Count[#,1]&/@ (Flatten[ ImageData[Binarize[ImageSubtract[ImageSubtract[#[[1]],#[[2]]],ImageSubtract[#[[2]],#[[3]]]]]]&/@ Partition[images,3,1],1]) *Note: before this code can be used, the backgrounds of the frames of the video have to be removed, and the image has to be binarized as much as possible (some examples will be shown in the next section). - Example code for the retrieval of raw data from DataDrop: rawData=Values[Databin["Serial#", {#}]]; data=Flatten[rawData["(xacc/yacc/zacc)"]]; --------------------------------- **Please feel free to contact me or comment if you are interested in the rest of the code ( uploading the C code to the Arduino, the manufacturer's code for the accelerometer, C code switch that lets Mathematica communicate with the Arduino, and the Wolfram Language code used to start each loop in the switch that retrieves data ). Also, I could send the classify function, or any other information that I might have left out; all suggestions welcome. [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=1.png&userId=602285 [2]: http://community.wolfram.com//c/portal/getImageAttachment?filename=2.png&userId=602285 Pablo Ruales 2017-01-11T01:15:04Z https://community.wolfram.com/groups/-/m/t/822762 Using the Wolfram Cloud in conjunction with an embedded Linux device allows one to create neat IoT applications. Here, by using a Beaglebone Black (BBB) and its plethora of IO ports, it was possible to control an RGB LED connected using the cloud. Although I'm using a Beaglebone Black for this project to show that it is possible to use Wolfram Language on other ARM devices, this can most likely be done in a similar manner on a Raspberry Pi. #Parts Used# - 1 x Common Cathode RGB LED - 3 x 220 ? Resistors - 4 x Jumper Wires - 1 x Beaglebone Black (of course!) The BBB is running Debian Jessie off of a MicroSD card. Since running the Mathematica front-end is a little resource heavy on the BBB, I would not suggest developing the functions in a notebook, but to create an .m file instead that contains all the functions and just `Get` the .m file in the notebook. For faster development, I recommend using `ssh` to connect to the BBB and editing the file using a terminal editor. ![Fritzing Diagram][1] In order for these instructions to work, you will need to run `CloudConnect[]` in a notebook and log in to your cloud account on your BBB. In order to be able to use our GPIO pins on the Beaglebone Black, we have to set them up. Here, I have connected the red pin to P9\_12, green to P9\_15, blue to P9\_23, and of course, DGND (reminder: this is common cathode!). If you're wondering what all that means, refer to [this][2] where P9\_12 is referring to pin 12 on the P9 header. ![enter image description here][3] Looking at the image, P9\_12 appears to be referring to GPIO\_60, P9\_15 to GPIO\_48 and P9\_23 refers to GPIO\_49. So, if you're using the same connections for your RGB LED as I am, you can go ahead and run the following code in the command line on the BBB as root: echo 60 > /sys/class/gpio/export echo 49 > /sys/class/gpio/export echo 48 > /sys/class/gpio/export For each pin, there is a file that is within the `/sys/class/gpio/gpio*` folder that sets the direction and another that sets the value. The following functions constructs the path to those files for a given pin and type (value or direction). file[pin_Integer, type_String]:= "/sys/class/gpio/gpio" <> ToString[pin] <> "/" <> type outputDigitalString[pin_Integer, type_String] := "echo " <> type <> " > " <> file[pin, "direction"] outputDigitalString[pin_Integer, bool_?BooleanQ] := "echo " <> ToString[Boole[bool]] <> " > " <> file[pin, "value"] The `outputDigitalString` function constructs a string command that specifies the direction and the value of each pin depending on whether the second argument is a string or boolean respectively. Since the digital pin’s direction has to be set first before outputting the value, the following function uses both strings constructed to set the direction and the value. outputDigital[pin_Integer, bool_?BooleanQ] := (Run[outputDigitalString[pin, "out"]]; Run[outputDigitalString[pin, bool]];) Finally, the following function is just a helper function to deal with the case when we provide the function with “pin1” instead of 1 to address the pins. outputDigital[s_String, rest___] := outputDigital[ToExpression@StringReplace[s, "pin" -> ""], rest] Next, we begin the functions that will allow us to communicate through the Wolfram Cloud. f[rules_] := CloudPut[rules, "ColorForm", Permissions -> "Public"] form = FormFunction[{{"pin60", "Red"} -> "Boolean", {"pin48", "Green"} -> "Boolean", {"pin49", "Blue"} -> "Boolean"}, f, “HTML”]; This makes a `FormFunction` that will have three checkboxes for each of the three colors. After submitting, the output will be `CloudPut` to a URI "ColorForm". Changing the permissions can be omitted if you would not like to share the link. Now, we will head over to our notebook (**Reminder: you must have Mathematica opened as root in order for this to work!**): Get["/home/debian/CloudFunctions.m"] Where you can change the `/home/debian/CloudFunction.m` to point to the .m file that you created. Next: CloudDeploy[form, Permissions -> "Public"] Again, it is not necessary to change the Permissions here if you're not planning on sharing the link. Run the code, and open the link that is given to you. From there, you can optionally choose a color(s) and submit. You will be redirected and a link will be given to you, which should have "ColorForm" at the end of the URL. Copy this URL and paste it into your .m file as `$formURL`. Then, go back to your notebook and run the following: oldInput = {}; While[True, userInput = Normal[CloudGet[CloudObject[$formURL]]]; If[oldInput =!= userInput, Replace[userInput, HoldPattern[tag_ -> value_] :> outputDigital[tag, value], 1]]; oldInput = userInput ] The reason for the creation of the `oldInput` variable is to make sure that the form has been changed, otherwise the LED will flicker as the BBB attempts to change the color. ![Form][4] There you have it! Now you can run the `While` loop and submit your colors through the form and watch them change *almost* immediately. If you would like to do a similar project with *more* color flexibility, take a look at [this][5]. This is my first post here and I would appreciate any feedback or suggestions! [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=8934RGBLEDDiagram.png&userId=766924 [2]: http://beagleboard.org/static/images/cape-headers.png [3]: http://community.wolfram.com//c/portal/getImageAttachment?filename=cape-headers.png&userId=11733 [4]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Form.png&userId=766924 [5]: http://community.wolfram.com/groups/-/m/t/824540 Armeen Mahdian 2016-03-13T17:44:07Z https://community.wolfram.com/groups/-/m/t/344241 Together with [Björn Schelter][1] I have tried to read in data from the personal weather station [Netatmo][2] ![enter image description here][3] which, as it turns out, is a very good companion for Mathematica; it also features in the [connected devices list of Wolfram][4].This device measures temperature, humidity, pressure, noise level and potentially the precipitation indoors and outdoors. Users are encouraged to share the outdoors data; as the weather station is rather popular there are lots of measurements. On their website [https://www.netatmo.com/][5] the company makes these measurements available. You can represent worldwide data ![enter image description here][6] (I know that that figure does not show the entire world!) or zoom in to street level data: ![enter image description here][7] On the website [https://dev.netatmo.com][8] you can sign up for a developer account which gives you access to the API of netatmo. In this post I am going to show how to access the data with Mathematica. When you sign up for a netatmo developer account you will be issued a client id and a client secret. These are rather long strings. You will also get a username and a password for your account. Next you need to request an access token, which you can do via the following command: > curl -X POST -d > "grant_type=password&client_id=AAAAAAAAAAAAAAAAAAAA&client_secret=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB > &username=XXXXXXXXXXXXXXXX&password=YYYYYYYYYYYYYYY&scope=read_station" > http://api.netatmo.net/oauth2/token> ~/Desktop/request-token.txt On a Mac I generate a file called netatmo.sh containing that string on the desktop; I obviously substitute AAAAAAAAAAAA by the client id, BBBBBBBBBBBBBBBB by the client secret, XXXXXXXXXXXX and YYYYYYYYYY by the user name and the password. Then I use the terminal command > chmod a+x netatmo.sh The rest is child's play. We need to execute the command Run["~/Desktop/netatmo.sh"]; data = Import["https://api.netatmo.net/api/getpublicdata?access_token="<>Last[StringSplit[Import["~/Desktop/request-token.txt", "CSV"][[1, 1]], "\""]] <> "&lat_ne=59.91&lon_ne=13.75&lat_sw=40.42&lon_sw=-20.0&filter=True", "Text"]; Note that the numbers following lat_ne, lon_ne, lat_sw, lon_sw are the north east and south west latitudes and longitudes. If we want to request data for other regions we can do so by changing these entries. Next we clean the data a little bit: tab = Quiet[ Select[Select[Table[ToExpression /@ Flatten[StringSplit[#, "]"] & /@ StringSplit[#, "["] & /@ If[Length[StringSplit[StringSplit[data, "place"][[k]], ","]] > 12, Drop[StringSplit[StringSplit[data, "place"][[k]],","], {5}], StringSplit[StringSplit[data, "place"][[k]], ","]]][[{2, 3, 7, 8, 15}]], {k, 2, Length[StringSplit[data, "place"]]}], Length[Cases[Flatten[#], $Failed]] == 0 & ], Length[#] == 5 &]]; That does look a bit cryptic but gives us what we want. tab[[1]] gives {10.5673, 59.8929, 13, 80, 1032.9}, wich are the gps coordinates, the temperature in Celsius, the humidity in % and the pressure in mbar. I will now propose three different representations of the data. scaled = Rescale[tab[[All, 3]]]; GeoGraphics[Table[{GeoStyling[Opacity[0.99], RGBColor[scaled[[k]], 1 - scaled[[k]], 0]], GeoDisk[{tab[[k, 2]], tab[[k, 1]]}, Quantity[20, "Kilometers"] ]}, {k,1, Length[tab]}]] which gives: ![enter image description here][9] The second representation is calculated using GeoRegionValuePlot[GeoPosition[{#[[2]], #[[1]]}] -> #[[3]] & /@ tab, PlotRange -> {0, 30}, ColorFunction -> "TemperatureMap", ImageSize -> Full] which looks like this ![enter image description here][10] Finally, the lengthy sequence of commands surface = Interpolation[{{#[[1]], #[[2]]}, #[[3]]} & /@ tab, InterpolationOrder -> 1]; cPlot = Quiet[ContourPlot[surface[x, y], {x, Min[tab[[All, 1]]], Max[tab[[All, 1]]]}, {y, Min[tab[[All, 2]]], Max[tab[[All, 2]]]}, ImagePadding -> None, ClippingStyle -> None, Frame -> None, Contours -> 60, ContourLines -> False, PlotRange -> {0, 30}, ColorFunction -> "TemperatureMap"]]; multipoly = Polygon[GeoPosition[Join @@ (EntityValue[EntityClass["Country", "Europe"], "Polygon"] /. Polygon[GeoPosition[x_]] :> x)]]; GeoGraphics[{GeoStyling[{"GeoImage", cPlot}], multipoly, Black, Opacity[1]}, ImageSize -> Full] gives this representation ![enter image description here][11] I am quite sure that with some modifications one can make a useful program out of this if one uses cloud deploy. Also, netatmo's data are updated every 30 minutes (every 5 minutes on the individual devices), so one can run a scheduled task and look at the development of the temperature. The large number of netatmo weather stations complements the data available from the Wolfram Data servers very nicely as they provide very up to date street level data. I would be glad to see a good idea of a cloud deployed service based on this or any other ideas that you might have. Cheers, Marco [1]: http://community.wolfram.com/web/bschelter [2]: https://www.netatmo.com/en-US/product/weather-station [3]: /c/portal/getImageAttachment?filename=ScreenShot2014-09-15at22.55.05.png&userId=48754 [4]: http://devices.wolfram.com/devices/netatmo-weather-station.html [5]: https://www.netatmo.com/weathermap [6]: /c/portal/getImageAttachment?filename=ScreenShot2014-09-15at22.59.02.png&userId=48754 [7]: /c/portal/getImageAttachment?filename=ScreenShot2014-09-15at22.59.37.png&userId=48754 [8]: https://dev.netatmo.com [9]: /c/portal/getImageAttachment?filename=netatmofig1.gif&userId=48754 [10]: /c/portal/getImageAttachment?filename=Netatmofig2.gif&userId=48754 [11]: /c/portal/getImageAttachment?filename=Netatmofig3.gif&userId=48754 Marco Thiel 2014-09-15T22:35:11Z https://community.wolfram.com/groups/-/m/t/170725 Sous vide is the method of cooking food in airtight bags using a water bath at a precise temperature. The method is fantastic to get the meat and seafood cooked evenly at the cooking point you love most. [url=http://modernistcuisine.com/2013/01/why-cook-sous-vide/]http://modernistcuisine.com/2013/01/why-cook-sous-vide/[/url] [url=http://www.douglasbaldwin.com/sous-vide.html]http://www.douglasbaldwin.com/sous-vide.html [/url] Buying an off the shelf sous vide can run for several hundreds of dollars. One of the many ways you can explore the world of modernist cooking is with your raspberry pi / some sensors and extra electronics/mathematica and a crock pot.   This initial posting will cover the very basic building blocks necessary for connecting to temperature gauges needed + turning on/off the crock pot. I hope that through the community postings we can all develop a full fledge solution using the Raspberry Pi that can allow you to monitor the temperature of the water bath, food, setting up the off/on temperatures, chart the cooking process, send SMS text /email when food is done, etc. Let's start with the basics. We'll need to turn on/off the water bath (crock pot). For that we'll need to control a relay. You can build your own circuit. Gaven McDonald's instructional video is a great starting point to build your own circuit and check how to connect the relay to your Raspberry Pi. [url=https://www.youtube.com/watch?v=b6ZagKRnRdM]https://www.youtube.com/watch?v=b6ZagKRnRdM[/url] You can buy a 2-relay module that works for Arduino/Raspberry just like this one. [url=http://www.sainsmart.com/arduino/arduino-components/relays/arduino-pro-mini.html]http://www.sainsmart.com/arduino/arduino-components/relays/arduino-pro-mini.html[/url] [url=http://www.sainsmart.com/arduino/arduino-components/relays/arduino-pro-mini.html][img=width: 500px; height: 500px;]/c/portal/getImageAttachment?filename=e11b1280bd72caccef99cdb9d60d4685.jpg&userId=11733[/img][/url] Opening/Closing the relay is straightforward with Mathematica. Using one of the available pins (ie PIN 17) you can power on /off the crockpot by using the command [mcode]DeviceWrite["GPIO",17->1][/mcode] Things get a little bit more challenging with taking temperature readings from the thermocouples. As BobtheChemist pointed out in his blog[mcode]http://www.bobthechemist.com/index.php/10-stuff/24-thanksgiving-pi[/mcode] The raspberryPi does not have analog pins in its GPIO (General Purpose Input Output). In his blog entry Bob shows how to overcome this limitation by using a capacitor and measuring how long it takes to charge it. For this entry, I decided to document the use of an analog to digital converter (ADC).  Checking out the web I found from several discussions and postings that the MCP 3008 would do the job. [url=http://www.adafruit.com/products/856]http://www.adafruit.com/products/856 [/url] We can use this transistor to hook up up to 8 analog sensors into our project. In our case, we'll only need two. One for the water bath probe and another for the food probe. The following wire diagram covers how to connect the MCP 3008 to the GPIO (Please focus on the right side of the MCP3008 wiring). [url=http://learn.adafruit.com/reading-a-analog-in-and-controlling-audio-volume-with-the-raspberry-pi/connecting-the-cobbler-to-a-mcp3008]http://learn.adafruit.com/reading-a-analog-in-and-controlling-audio-volume-with-the-raspberry-pi/connecting-the-cobbler-to-a-mcp3008[/url] For the thermocouples, you need to watch out on the type of thermocouples you get. For this specific project the replacement probes for the Maverick ET-73 will work just fine. [url=http://www.amazon.com/gp/product/B004W8B3PC/ref=oh_details_o00_s00_i00?ie=UTF8&psc=1]http://www.amazon.com/gp/product/B004W8B3PC/ref=oh_details_o00_s00_i00?ie=UTF8&psc=1[/url] The thermocouples must be connected to the MCP3008 channels CH0 and CH1 in the following manner. [img=width: 240px; height: 320px;]/c/portal/getImageAttachment?filename=photo.JPG&userId=78214[/img] We do need to determine the value needed for the fixed resistance. The best value would be equal to the one expected when we reach the cooking temperatures. As I like my steaks medium I chose 60C as the point to use. Using a thermometer, the thermocouples and a multimeter, I measured the temperature of a ice water glass, hot water and warm water. Using the three points, we can find the function that represents the temperature based on the resistance of the thermocouple.[mcode]temp = {20.6, 42, 83.3} + 273.15 resistance = {220650., 95800., 26340.} data = Transpose[{Log@resistance, Log@temp}] lm = LinearModelFit[data, x, x] lm[{"RSquared"}][/mcode]The model fits very well R^2=0.998 What is the expected resistance at 60C? [mcode]invdata = Transpose[{Log@temp, Log@resistance}] Fit[invdata, {1, x}, x] (*74.3895 - 10.9297 x*) f[x_] := 74.38949510675315` - 10.929736543045369` x Exp[f[Log[60 + 273.15]]] (*54344.9*)[/mcode]Thus I used 56K Resistors for the thermocouples. Now, to the function needed to read the thermocouples value. We have to probe the analog inputs from the MCP 3008 via the GPIO.  We can use the library for the MCP 3008 developed by Gabriel Perez-Cerezo [url=http://gpcf.eu/projects/embedded/adc/]http://gpcf.eu/projects/embedded/adc/[/url] There are two libraries needed gpio.h and mcp3008.h.  Dropped them both into /usr/include directory in the Raspberry Pi The other very important step necessary is exporting the GPIO pins into /sys/class/GPIO, Gabriel also provides the script needed in hist web page. Please make sure to follow his intructions found in the comment section of the script. I forgot to run the [b]update-rc.d -f gpio defaults [/b]command after the installation and spent quite of bit of time after rebooting the equipment several days later. Was getting an error in Mathematica (and a c program to check if the reading was working, kept getting a segmentation fault error) all because the step needed for the script to run at startup was not in place. Once we have the libraries in place we can address building a function with MathLink to get the readings from the MCP 3008 Please refer to the mathlink developer guide for more details in how it works [url=http://reference.wolfram.com/mathematica/tutorial/MathLinkDeveloperGuide-Unix.html]http://reference.wolfram.com/mathematica/tutorial/MathLinkDeveloperGuide-Unix.html[/url] Built the two files needed for the function adc.tm[code]:Begin: adc :Pattern: adc[adc_Integer, clock_Integer, in_Integer, out_Integer, cs_Integer] :Arguments: {adc, clock, in, out, cs} :ArgumentTypes: {Integer, Integer, Integer, Integer, Integer} :ReturnType: Integer :End: [/code]adc.c [code]#include <mathlink.h> #include <mcp3008.h> int adc(int adc, int clock, int in, int out, int cs) { return mcp3008_value(adc, clock, in, out, cs); } int main(int argc, char *argv[]) { return MLMain(argc, argv); }[/code]After creating both files, I proceeded to compile the program with the following command. This generated the necessary function that can now be invoked from Mathematica or the wolfram engine as follows. [mcode]Install["/home/pi/mathematica/adc/adc"]; (*We can now call function adc to read the voltage drop at the thermocouple The voltage reading will be read by the MCP as a value between 0 (0V)to 1023 (3.3V) *) (* Analog Channel = 0, ClockPin = 18, In = 23, Out =24, CS = 25 *) adc[0, 18, 23, 24, 25] (*The following function translates the voltage reading to temperature in Celsius*) temp[channel_] := Module[{R2 = 56000, a = -0.0913946, b = 6.80504, R1, x = adc[channel, 18, 23, 24, 25]}, R1 = (1024 - x) R2/x ; Exp[a Log[R1] + b] - 273.15] (*Function datapoints is used to collect temperature readings in a matrix of length maxPoints. It also controls the relay to turn on the crockpot when the temperature reading is below the setpoint and turn it on when above the set point*) datapoints[myList_List, fn_, maxLength_Integer, setPoint_Integer] := Module[{x, val = fn}, x = Append[myList, {DateList[], fn}]; If[val < setPoint, DeviceWrite["GPIO", 17 -> 0], DeviceWrite["GPIO", 17 -> 1]]; If[Length[x] > maxLength, x = Take[x, -maxLength], x]] data={}; (*Using a Chart to establish the setpoint and graph the temperature trend *) Manipulate[ DateListPlot[Refresh[data = datapoints[data, temp[0], 300, setPoint], UpdateInterval -> 15, TrackedSymbols -> {}], Joined -> True, PlotRange -> {Automatic, {20, 100}}, GridLines -> {Automatic, {setPoint}}], {{setPoint, 60}, 30, 80, 1, Appearance -> "Labeled"}] [/mcode][img=width: 407px; height: 336px;]/c/portal/getImageAttachment?filename=7.png&userId=78214[/img] This is a link to the video that shows the program running and controlling the relay. [url=http://youtu.be/4ae42ctVZuk]http://youtu.be/4ae42ctVZuk[/url] Next challenge will be to use the Web Server functionality of the Raspi to interact with Mathematica so as to control the set point and chart the temperature curve via a web page. ... to be continued. Diego Zviovich 2013-12-14T07:37:04Z https://community.wolfram.com/groups/-/m/t/453169 Yesterday, [Stephen Wolfram announced][1] the release of this great solution for storing and sharing data coming from sensors, devices, programs, humans or anything else: the [Wolfram Data Drop][2]. I think this is a turning point; it completely changes the game on how I've been interacting with streams of data. In this post I want to share with you three ideas that I've been exploring using the [Raspberry Pi 2][3], which, by the way, it runs Mathematica about 10x faster than its predecessors! ![Data Drop on the Raspberry Pi][4] ![enter image description here][5] ![enter image description here][6] The first idea that came to my mind was to revisit some of the experiments I had carried out in the past, like this [home alarm system][7]. In a matter of minutes, I was able to set up an activity tracker for my home's hall. Every time I pass by, the [PIR motion sensor][8] adds a 1 to the "mov" variable that is being dropped to [this databin][9] every 20 minutes. Check it out in [W|A][10], it's live and growing! [== Data drop 3v1UbpOM][11] ![My home hall's activity][12] ![Periodic entries][13] This is such a great thing, that dataset is just about me but it could be monitoring whatever you want, like your cat's crazy habits. For this example the data is being logged periodically but you could set it up in an event-based manner. Like here, whenever a movement is detected, it triggers the [RaspiCam][15] and it sends the snapshot to the following databin: ![RaspiCam Databin][16] ![Cumulative Activity Plot][17] What about making a several days long time-lapse of you? ![Daily work at home][18] Or what about using other sensors? The possibilities are just endless! Finally, let me end up with the following collaborative activity for the classroom. Here is how you can carry it out. First, you create a public databin to add two different names of animals that the students will enter: CreateDatabin[ "Interpretation" -> {"animal1" -> "Animal", "animal2" -> "Animal"}, <|"Name" -> "Classroom Zoo"|>] Then, ask your students to submit their favorite animals' names, using the web-based platform http://wolfr.am/3zCzVgPJ ![Add new entry][19] Their individual entries will ended up generating things similar to this amazing [Graph][20]! data = Values[Databin["3zCzVgPJ"]]; pairs = Apply[Rule, Drop[Transpose[{data["animal1"], data["animal2"]}], 9], {1}] ![Name pairs][21] pics = Map[# -> #["Image"] &, Union[Flatten[Drop[Transpose[{data["animal1"], data["animal2"]}], 9]]]]; style ={ VertexSize->1.2,EdgeStyle->Directive[Arrowheads[{{.02,.6}}],Hue[.4,1,.3]],VertexShape->pics}; Graph[pairs, style, ImageSize -> 900] ![Animals Graph][22] Please, give [it a try][23]. Later, we will see what the giant graph ends up looking like. Or even more fun, share with us your ideas or databins that you want to be filled out collaboratively! [1]: http://blog.wolfram.com/2015/03/04/the-wolfram-data-drop-is-live/ [2]: https://datadrop.wolframcloud.com/ [3]: http://www.wolfram.com/raspberry-pi/ [4]: /c/portal/getImageAttachment?filename=RaspberryPi_Data_Drop.png&userId=56204 [5]: /c/portal/getImageAttachment?filename=raspberry-pi-01.png&userId=56204 [6]: /c/portal/getImageAttachment?filename=raspberry-pi-02.png&userId=56204 [7]: http://community.wolfram.com/groups/-/m/t/226163 [8]: http://www.adafruit.com/products/189 [9]: http://wolfr.am/3v1UbpOM [10]: https://www.wolframalpha.com/input/?i=Data%20drop%203v1UbpOM [11]: https://www.wolframalpha.com/input/?i=Data%20drop%203v1UbpOM [12]: /c/portal/getImageAttachment?filename=activity.png&userId=56204 [13]: /c/portal/getImageAttachment?filename=entries.png&userId=56204 [14]: /c/portal/getImageAttachment?filename=MyHomeHallActivity.png&userId=56204 [15]: http://community.wolfram.com/groups/-/m/t/157704 [16]: /c/portal/getImageAttachment?filename=HomeActivity.jpg&userId=56204 [17]: /c/portal/getImageAttachment?filename=cumulativePlot.png&userId=56204 [18]: /c/portal/getImageAttachment?filename=timelapse_Bernat.gif&userId=56204 [19]: /c/portal/getImageAttachment?filename=inputDD.png&userId=56204 [20]: http://reference.wolfram.com/language/ref/Graph.html [21]: /c/portal/getImageAttachment?filename=ClassZoo.jpg&userId=56204 [22]: /c/portal/getImageAttachment?filename=AnimalsGraph.jpg&userId=56204 [23]: http://wolfr.am/3zCzVgPJ Bernat Espigulé 2015-03-05T15:01:41Z https://community.wolfram.com/groups/-/m/t/505425 I built a train detector (OK, I hooked up a microphone to a Raspberry Pi 2). I record CD quality sound (44.1 kHz) to a sound file and run it through a C program to perform a FFT. You can then easily detect the signature of train whistles from the frequency spectrum. I then record and display the data using a conventional Spring Boot / MySQL application. All of this is running on a Raspberry Pi 2 with a 32 GB sim card. You can see it working at: [**Train Counter**][1] **Code is at:** https://github.com/geocolumbus/traindetector I've gotten as far as recording the time between trains, **and now I want to predict when the next train will come**. I think this is a classic statistics problem - "time between events" and "predict the probability of the next event". **Any ideas on how to proceed?** Sample data are attached. ![enter image description here][2] [1]: http://www.traincounter.com [2]: /c/portal/getImageAttachment?filename=2015-05-27_12-39-52.png&userId=11733 George Campbell 2015-05-27T13:07:50Z https://community.wolfram.com/groups/-/m/t/1153218 ![Controlling a Meccano G15 KS robot with the EZ-Robot system][1] Hi there, (Sharing an idea) I am a hobbyist user of Mathematica. I am using it to control my three robot systems. Firstly there is Jeeves. It is a modified Meccano G15 KS. The Meccano control system has been removed and replaced with another control system (EZ-Robot). This new controller and its PC based control software is capable of starting an external program. In my case that external program is Mathematica. The sensors on the robot read in data and pass these data onto the PC based control software which then fires up Mathematica which in turn carries out some computation and passes a result back to the PC based control software. Data is stored in files. Using this set up means there can be latency. Sometimes quite a bit. For me this is not a problem as the robot is mainly used to test algorithms. Waiting a minute for a result is not an issue. ![Modified Meccano G15 KS][2] This robot can read text from a sheet of paper or screen and then repeat what it has seen. It can also read text and evaluate it. For example given the question, "What is the capital of England" the robot will reply "London". It can recognise objects in an image(potentially thousands). By reading in text similar to the following "AABBCCD", it will play sounds relating to the musical notes. All this is made possible because of Mathematica. As stated above I use this robot for algorithm testing. In this case Mathematica is used indirectly. My second robot is a small 16 DOF humanoid robot. This robot is controlled by a 24 channel Pololu Maestro servo controller. ![Modified EZ-Robot][3] ![Rear of modified EZ][4] Now this robot is controlled directly by Mathematica. All code is contained in a notebook and uses all the features of connected devices contained within Mathematica. Data can be read from and sent to the robot. Just by using the Manipulate function every servo in the robot can be controlled by Mathematica. I have not done so at the moment but to create a robot animation system with Mathematica would only be a few dozen lines of code. That is one of my first tasks. This robot is a modified EZ-Robot now totally under the control of Mathematica. My third robot is a robot workbench. Built by me to test more complex algorithms. This is controlled by a 24 channel Pololu Maestro servo controller. In turn controlled completely by, you guessed Mathematica. ![Robot Workbench 1][5] ![Robot Workbench 2][6] ![Robot Workbench 3][7] ![Robot Workbench 4][8] ![Robot Workbench 5][9] The robot workbench only has a servo control program written at the moment. This control program makes use of the Manipulate function. I have some great plans for this workbench in the future. Under the control of Mathematica it will perform tasks using all the power of the neural networks and machine learning. Image and text processing. To name but a few. My big goal is to create a Robot Operating System that will contain all the code required for the robots to carry out complex tasks. This would include features such as inverse and forward kinematics. I want to achieve this using only Mathematica. My reason for putting my robots on the forum is simply to see if anyone is doing anything similar. With only a few lines of Mathematica code I have been able to get the robots to read text and interpret it. I am sure that my Robot Operating System will be thousands of lines of code. I plan to write it in two parts. A front end to carry out general robot tasks, such as movement and manipulation, data processing from sensors and the solving of problems using neural nets and machine learning. A back end that can be made to match up to a specific controller or micro controller. That is my plan. Any code I produce will be made available to this forum. Well I had better get back to coding. ---------- # CODE ---------- The code for the G15 KS simply performs a task and returns a result to the control software of the robot. There is no direct control. The humanoid robot and the workbench code have direct control. The following is the code that allows the modified G15 KS to read text and repeat what it has seen. str = TextRecognize[Import["C:\\mathscripts\\images\\img3.jpg"], Language -> "English"]; str = StringReplace[str, Whitespace -> " "]; str s = OpenWrite[File["C:\\mathscripts\\jeeves\\output.txt"]] WriteLine[s, str]; Close[s]; Here the image taken by the robots camera is picked up by mathematica and the TextRecognize function gets the text from the image and stores it in a file ready to be used by the robots control system. Pretty simple coding to get a robot to read text. The following code allows the G15 KS to read text, evaluate it. str = TextRecognize[Import["C:\\mathscripts\\images\\img3.jpg"], Language -> "English"]; str = StringReplace[str, Whitespace -> " "]; str s = OpenWrite[File["C:\\mathscripts\\jeeves\\output2.txt"]] res = Interpreter["SemanticExpression"][str]; If[NumericQ[res], res = N[res], res] WriteLine[s, ToString[res]]; Close[s]; The following code allows the G15 KS to identify an object within an image. Actually thousands of objects' txt = ImageIdentify[Import["C:\\mathscripts\\images\\img3.jpg"]] s = OpenWrite[File["C:\\mathscripts\\jeeves\\output3.txt"]] WriteLine[s, ToString[CommonName[txt]]]; Close[s]; The following code allows the G15 KS to read text relating to geographic location. This was used by the robot to read the text generated by a mobile phone app and speak the result. str = TextRecognize[Import["C:\\mathscripts\\images\\img3.jpg"], Language -> "English"]; str = StringReplace[str, Whitespace -> " "]; str = StringSplit[str]; If[NumberQ[ToExpression[str[[1]]]] && NumberQ[ToExpression[str[[2]]]], $GeoLocation = GeoPosition[{ToExpression[str[[1]]], ToExpression[str[[2]]]}]; country = CountryData[$GeoLocationCountry, "Name"]; citytown = CityData[$GeoLocationCity, "Name"]; s = OpenWrite[File["C:\\mathscripts\\jeeves\\output4.txt"]]; WriteLine[s, country <> " is the country I am in and the nearest town or city is called " \<> citytown]; Close[s];, s = OpenWrite[File["C:\\mathscripts\\jeeves\\output4.txt"]]; WriteLine[s, "Invalid input Please try again " ]; Close[s];]; The following code allows the robot to play a tune. The text the robot must read is as follows: AABBCCD str = TextRecognize[Import["C:\\mathscripts\\images\\img3.jpg"], Language -> "English"]; str = StringReplace[str, Whitespace -> ""]; str s = OpenWrite[File["C:\\mathscripts\\jeeves\\output5.txt"]] WriteLine[s, str]; Close[s]; It can be seen from the code that most of the work is passing data in files. The code to carry text and image analysis is simply one line of code. It can not get better than that. The code that follows is the code the is used to control all of the humanoid and workbench servo. Firstly the workbench. Button["Open connection to Maestro", dev = DeviceOpen["Serial", "COM5"]] Manipulate[ DeviceWriteBuffer[ dev, {132, 1, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1224, "Right Base"}, 496, 2016, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 0, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1224, "Left Base"}, 496, 2016, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 3, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1216, "Right Pivot"}, 1008, 2000, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 2, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1216, "Left Pivot"}, 1008, 2000, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 4, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1216, "Right Elbow"}, 1024, 2144, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 5, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1270, "Left Elbow"}, 1024, 2144, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 14, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1240, "Right Wrist"}, 496, 2000, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 15, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1182, "Left Wrist"}, 496, 2000, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 7, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1200, "Right Gripper"}, 1024, 1296, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 6, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1200, "Left Gripper"}, 1024, 1296, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 8, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1480, "Turn Table"}, 992, 2000, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 10, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1240, "Move Vertical"}, 496, 2000, 1}] Manipulate[ DeviceWriteBuffer[ dev, {132, 11, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}], {{a, 1200, "Move Horizontal"}, 800, 1600, 1}] CloseDevice[dev]; Now the code to move the humanoid servos using Manipulate. dev = DeviceOpen["Serial", "COM5"] Manipulate[ DeviceWriteBuffer[ dev, {132, 0, BitAnd[a*4, 127], BitAnd[BitShiftRight[(a*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 1, BitAnd[b*4, 127], BitAnd[BitShiftRight[(b*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 2, BitAnd[c*4, 127], BitAnd[BitShiftRight[(c*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 3, BitAnd[d*4, 127], BitAnd[BitShiftRight[(d*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 5, BitAnd[e*4, 127], BitAnd[BitShiftRight[(e*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 4, BitAnd[f*4, 127], BitAnd[BitShiftRight[(f*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 6, BitAnd[g*4, 127], BitAnd[BitShiftRight[(g*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 7, BitAnd[h*4, 127], BitAnd[BitShiftRight[(h*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 15, BitAnd[l*4, 127], BitAnd[BitShiftRight[(l*4), 7] , 127]}]; DeviceWriteBuffer[ dev, {132, 14, BitAnd[k*4, 127], BitAnd[BitShiftRight[(k*4), 7] , 127]}], {{a, 1224, "Left Base"}, 496, 2016, 1}, {{b, 1224, "Right Base"}, 496, 2016, 1}, {{c, 1216, "Left Pivot"}, 1008, 2000, 1}, {{d, 1216, "Right Pivot"}, 1008, 2000, 1}, {{e, 1270, "Left Elbow"}, 1024, 2144, 1}, {{f, 1270, "Right Elbow"}, 1024, 2144, 1}, {{k, 1024, "Right Wrist"}, 496, 2000, 1}, {{l, 1024, "Left Wrist"}, 496, 2000, 1}, {{g, 1200, "Left Gripper"}, 1024, 1296, 1}, {{h, 1200, "Right Gripper"}, 1024, 1296, 1}] That's all for now at a later date there will be a lot more to come. It can be seen from above that very little code is required to get a great deal of functionality. [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Main111120224.png&userId=20103 [2]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_204150%282%29.jpg&userId=1152078 [3]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_210215%282%29.jpg&userId=1152078 [4]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_210324%283%29.jpg&userId=1152078 [5]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_205616%282%29.jpg&userId=1152078 [6]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_205908%282%29.jpg&userId=1152078 [7]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_210128%283%29.jpg&userId=1152078 [8]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_204931%282%29.jpg&userId=1152078 [9]: http://community.wolfram.com//c/portal/getImageAttachment?filename=20170722_205445%282%29.jpg&userId=1152078 Terence Smith 2017-07-26T17:11:41Z