1. Resolving the questions revolving around the NAR LSB requirement.
  1. The requirement in question is STSR 4.5.2 here: https://opendesignengine.net/projects/shepard-ts/wiki/Requirements_Document_v1_0
  2. Jeremy is supposed to call a NAR representative before the hangout to follow up on an email he sent in regards to this.
  1. Was the call made and did we get the information we needed?
  1. Jeremy (Before Hangout Update) - Yes, I made the call and talked to John. He said that they can/do test multiple motor sizes per stand and have to deal with this issue. They use an Analog Devices 8524 instrumentation amplifier. I have not been able to find this part number yet. The idea is that they adjust the gain to fill the ADC’s resolution. We’ve talked about this before, but now we have confirmation that’s how it’s done.
  2. Wilton - This gets to be a little more spendy. Calibration and accuracy are just going to have to take a hit on this. The Arduino is great, but isn’t really designed to do that.
  1. Use an FPGA for a future version, create your own firmware, and use that as a bolt on upgrade for the Arduino. You could create a shield for this. There are shields for this.
  1. http://dangerousprototypes.com/2011/06/30/papilio-fpga-shield-for-arduino/
  2. http://www.cutedigi.com/arduino/butterfly-one-papilio-one-250k-arduino-fpga-version.html
  1. Wilton - We wouldn’t want to cut the Arduino out.
  1. We would want to solve the DAQ issues with v2.0.
  1. Use external crystal oscillator. High res ADC.
  1. This needs to be resolved so that we at least know if we’re going to miss the mark with version 1.0 of Shepard. We just need to accept the lower specs that we’re going to get.
  2. Ethan says that someone down the street from them (Masten) uses a bathroom scale to measure thrust.
  3. Wilton shared a link on doing DAQ with Arduino. https://sites.google.com/site/measuringstuff/the-arduino
  4. Wilton - We’re going to have a lot of jitter with the Arduinos. The internal clock is very susceptible to thermal noise. You won’t be sampling at the time slice that you think. Becomes a bigger deal when measuring an analog world.
  1. Load cell selection
  1. Item 1 above directly influences this.
  2. There is a fairly tight coupling between the mechanical and DAQ systems at this point.
  3. Possible load cells (from Resources discussion https://opendesignengine.net/boards/4/topics/1):
  1. http://www.robotshop.com/compression-load-cell-10-lbs.html?utm_source=google&utm_medium=base&utm_campaign=jos
  2. http://www.robotshop.com/compression-load-cell-100-lbs.html?utm_source=google&utm_medium=base&utm_campaign=jos
  3. http://www.pasco.com/prodCatalog/CI/CI-6537_force-sensor/
  4. http://www.sparkfun.com/products/10245
  5. http://www.trossenrobotics.com/p/phidgets-force-sensor.aspx?feed=Froogle (Requires their custom USB interface)
  6. http://www.trossenrobotics.com/c/robot-force-sensor-fsr.aspx
  7. Can you source the load cells that would normally be used in digital kitchen scales?
  8. What others are there that will fit within our price range and meet our requirements?
  9. Jeremy - Wondered if these were an option. http://www.trossenrobotics.com/c/robot-force-sensor-fsr.aspx
  1. Wilton - Worried about the fact that they’re not linear. Hysteresis may also be an issue.
  2. We would have to do post-processing of the log based values that we got back from these load cells. That’s to convert from analog voltage to a force.
  3. Greg - Would be interested to try out one of these force resistive force sensors.
  4. Jeremy - Would you use a Wheatstone bridge?
  1. Wilton - Needs a feedback system.
  2. Wilton - We could, but we could just run a current through it and use a pull-up resistor to measure voltage.
  1. Would be good to help us keep within the $200 constraint.
  1. Signal conditioning?
  1. This will depend on the load cell we select.
  2. Wilton - For the force sensing resistors, we could use something like a unity gain amplifier. http://banananan.wordpress.com/2012/01/12/pressure-sensor-arduino-processing-signal-analysis/
  1. This trades accuracy for simplicity, time and money.
  1. We need to confirm the reimbursement policy with J.
  2. Wilton - This will meet the spirit of what we’re trying to achieve and be a good platform to build off of.
  1. Thermocouple Selection
  1. Thermocouples
  1. There’s some discussion about thermocouples on the following forum discussion (look at the bottom post by Ben Barnett). https://opendesignengine.net/boards/4/topics/14
  2. http://www.sparkfun.com/products/251 (thermocouple)
  3. http://www.sparkfun.com/products/306 (thermocouple amplifier)
  1. Signal conditioning
  1. http://ryanjmclaughlin.com/wiki/Arduino_Thermocouple_Shield
  2. http://www.robotshop.com/productinfo.aspx?pc=RB-Ada-13&lang=en-US
  1. Jeremy - How does the combo of the SparkFun load cell and AdaFruit amplifier sound?
  1. Greg found the thermocouple and amplifier both from SparkFun. Links 251 and 306 above.
  2. Wilton - The inputs for the AdaFruit model are differential, so that would be his preference.
  3. Jeremy - Consensus is that Adafruit amp with SPI interface and the SparkFun thermocouple are the way to go.
  1. Data logging
  1. Do we want to collect the data, buffer it, and then try to ship it over USB fast enough, or use something like the Data Logging Shield?
  1. http://adafruit.com/products/243?gclid=CJC6h_CN8bACFQ8KKgodWyt3vA
  2. Will the data logging shield even allow us to do what we want?
  3. How are we going to transport the data between the Arduino and computer?
  1. USB?
  2. SD card via SneakerNet (would require the data logging shield)?
  1. Wilton - Would like to see us stream the data over USB as it’s acquired. Cuts down on the amount of hardware used, and 1kHz isn’t that fast.
  2. Wilton’s preference would be to do post processing after the data is collected.
  1. Programming languages
  1. J mentioned in the hangout last night that we should not forget about the Processing language on the computer side of the data acquisition.
  1. It was at least partially designed to handle things like plotting, and it would make the barrier to entry lower for students and non-developer types.
  2. J said there seems to be a preference for Processing in the Arduino world because Wiring and Processing are so similar.
  1. Wilton - The Processing app would be a terminal emulator that would accept data from the Arduino and dump it to a file. Then you can use GNUPlot for everything else for now. Eventually we’d want Processing to handle the plotting.
  2. Jeremy - The consensus is to go ahead and using Processing as the language. For the Arduino we’ll use Wiring.
  3. On Wiring for the Arduino
  1. If we cannot sample fast enough on the Arduino using Wiring, are we willing to drop back to C, or will we just accept the sample rate we get?
  2. Wilton - Doesn’t think that speed will be a problem. It’s going to be a small loop where we’re doing sampling. The only concern right now is whether or not we’ll be able to send the data over the USB communications channel fast enough to prevent hiccups. You can only send changed values instead of every value, don’t use extra characters. Just send numbers.
  1. Wilton - If we’re careful to be consistent with our sample rate we don’t have to worry about time stamps. You could make the timestamp a heartbeat.
  1. We should try to put the timestamps in and then scale back from there if there’s too much data to send.
  1. There seems to be a consensus on this.
  1. We have to accept that opinions on programming languages are varied and passionate, so there will always be disagreement about languages.
  1. We need to select the language based on what best promotes the goals of the project (like facilitating educational exploration of rocket science).
  1. Wilton - Uneasy about load cell. Worth giving a try, but not sure it will work. He prefers to convert log to linear in the analog world rather than trying to deal with it in the digital world.
  1. Jeremy - We’ll make trying this out a priority so that we can back up and try another route if we have to.
  1. ACTION - Jeremy to email J to tell him which route we’ve chosen and get the ball rolling on getting a sample(s) to try.
  1. Wilton - We need to check what load cell the NAR uses. If we can meet or exceed those specs we know we’re on the right track. Would be good for a reference point.
  1. ACTION - Jeremy needs to call John Lyngdal tomorrow to find out which load cell NAR uses.

We need to make sure that this hangout focuses on answering any questions involving the DAQ section of the block diagram. The sections above are designed to help facilitate that, but any items that have been missed from the diagram should be brought up. https://opendesignengine.net/projects/shepard-ts/wiki/Block_Diagram_v1_0