Future Design Discussion - v2.0

Added by Jeremy Wright almost 11 years ago

This has been copied from an email conversation about Shepard requirements.

Aaron Harper wrote:

I think the NAR measurement was concerned about burn-thru, otherwise there is no reason to measure temperature at those two points. I didn't see anything about sensor specs, lag and slew rates, measurement resolution, or time resolution, and I get the feeling that these may have been outside the skill set of the NAR spec writers. This means we will probably have to write our own.

Some possible specs to yield a usable dataset:

1. The temperature sensor must be used in accordance with it's design. A contact sensor such as a thermocouple must be put in contact with the motor casing, while a non-contact (IR) sensor may need to be placed a minimum distance away from the casing to form a valid thermal image.

2. The temperature sensor must be able to read 50% or more of the temperature which would destroy the motor casing, ie. if the casing will ignite at 500F, the sensor must be able to measure to 250F as a minimum. This refers to the sensor's specification, not the calibration of the measurement circuit's full scale.

3. The temperature sensor must be read as an analog value with a minimum of 8 bit precision. This will allow a very small change to be spotted even if it were to occur in a destructive event since the system could register a change as small as 0.004 degrees in the above example.

4. The temperature measurement system must read the temperature at least 32 times during the engine thrust cycle. In a 1/2A3-2T, the system must measure the temperature at least 32 times during the 3 second propellant burn. This is a measurment every 93mS or a frequency of 10.67Hz.

5. The sensor must be able to yield valid data at least 1/8 of the way through the test. This means that in the example above, the sensor may not lag more than 375mS.

Thoughts?


Replies (30)

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

With the exception of the IR sensor, this seems like a good requirements discussion for Shepard 2.0.

Here's the IR setup that Aaron had in mind: http://www.ti.com/product/tmp006

In reference to #4, what do we do if we sample at 800 or 1000 samples per second? Do we throw away the in-between samples where the response of the thermocouple is still catching up? How do we even figure that out? Do we just go by the published response time of the thermocouple?

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

The figures were to define the minimum resolution. If you can pull 1000 samples per second at 16 bit resolution, that would be even better!

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

Thanks Aaron. I didn't realize you were referring to the minimum resolution.

Switching gears:

An idea that's been rattling around in my head for awhile is that it might be cool to have some sort of client-server model in the software for this version. What I'm thinking is that the software would run as it does now, with the charts, and control buttons, etc, but that the program would also act as a server. What I thought would be really cool would be for people to be able to connect with their smartphones, tablets, and laptops, and pull up a read-only web interface where they could watch the test run. Then maybe they'd have a button that would allow them to download the last run's test results. This would give students a great tool to watch and analyze test results in almost real time, and would be very cool when the test stand is being demo'd at events like OHS (Open Hardware Summit). If there wasn't a WIFI connection available at the event center, we could have an open wireless AP set up connected to the laptop running the software, and people could hop on it with their mobile devices and watch as we touch the sensors.

Are there any thoughts on that? I can't guarantee that it would be done in time for OHS, but I think it would be a cool addition to a kit that's being built primarily as an educational tool.

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

Yaknow, I had a similar thought, though I was not thinking about Shepard... It makes sense though, as this would give us the ability to do a much richer presentation. To accomplish this, you will need something with a lot more horsepower than an Arduino or MSP430. For not much more money we could use a RaspberryPi which not only has a full fledged ARM processor and TCP/IP stack, it also runs Linux allowing the server implementation to be easy and powerful. The down side to the Pi is their perennial supply issues (though these are clearing up) and the fact that their Ethernet implementation runs off the USB bus. Another possibility is using a Beaglebone for this task. While they originally ran $89.00, the new version will have more memory, run faster, have built in HDMI, and be cheaper, though by how much is currently a well guarded secret.

Both of these solutions have I/O headers with I2C and SPI capabilities, so it wouldn't represent any major redesign of the sensor suite. The gotcha is the voltage levels... and I don't remember off the top of my head what they are for the Pi and Bone. I2C signaling defines the protocol, not necessarily the levels, and I have seen them range from 1.8 to 12V, though 3.3 and 5V are the most common for our purposes. My recommendation goes with the Bone, primarily because I already have one. When you get ready to play with this, let me know and I'll send it to ya unless it's in another project by then. I doubt it will be since it is overkill for most things that I do; the MSP430s I have been playing with do fine.

Programming both the Pi and Bone are considerably easier than dealing with the oddities of the arduino or sometimes stubbornness of the MSP430 (C was never a strong point with me). Since it is a Linux system, programming can be accomplished by anything from C++ to shell scripting. The bone's I/O can be operated directly form the OS file system, and this really makes things easy... plus it has it's own built in web based IDE. Have a look at these videos: http://youtu.be/Y0uqRVxismQ and http://youtu.be/z6b4zlh0IrE. The challenge will be making an extensible set of gauges, buttons, strip charts, and other widgets so that the interface we build can be plugged into any other project we come up with, cutting dev time considerably.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

I was actually thinking that the laptop that's receiving the data from the Arduino would be the server, but combining everything into one unit is an interesting idea.

I would agree that the supply issues with the Pi is a downside. In my mind it's a deal killer, and I dropped the Pi on one of my business projects for that reason. I do like the Beaglebone idea though. I haven't used one yet, but I've read quite a bit about it. There's some additional cost over the Arduino with the Bone, but one of the thrust sensors we're looking at using for version 2.0 is only $5, which would free up some of the budget.

My thought is that we not get too wrapped up in this (by not building a test setup) until version 1.1 is out of the way, but I would like to continue the conversation. I think there are some interesting things we can do here. J has brought up the idea before of people paying a few dollars at events to press the ignition button and get the data from "their" test run. We could do some really cool things with crowd participation with this kind of model.

If we used a Bone with a hardware control panel (safety switch, ignition button, recording enabled switch, etc) we could divorce the test stand from a directly connected laptop completely if we wanted.

RE: Future Design Discussion - v2.0 - Added by Ben Barnett almost 11 years ago

Quote:
"2. The temperature sensor must be able to read 50% or more of the temperature which would destroy the motor casing, ie. if the casing will ignite at 500F, the sensor must be able to measure to 250F as a minimum. This refers to the sensor's specification, not the calibration of the measurement circuit's full scale."

Thoughts:

How does #2 make any sense? Temperature scales are arbitrary, except the "Thermodynamic Kelvin Scale", where "50% or more of the temperature..." makes even less sense.

It seems to me that a case temperature sensor should be able to read case temperature up to, and including the temperature at which the case could be reasonably expected to fail. Philosophically, in any test setup where the D-U-T might fail destructively, all sensors should remain functional a far as practical through the failure process. After all, the whole idea of testing is to analyze potential and actual failure modes in addition to characterizing performance.

My $.02,
Ben

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

Divorcing the control system from the Laptop is probably the biggest advantage to this topology. The trouble is that a web interface on the arduino or MSP430 is simply not capable of serving the page(s) to multiple users. One or two may be okay, but beyond that things slow to a crawl. It's also a colossal PITA to code the TCP/IP stack or implement someone else's. What I would like to see is a web server and framework in which pages can be configured for open access, multiple login, or single login. Example: a public access page with the real time run data (non-interactive) and an administrative page where only one person can be logged in, but is capable of running calibration routines, moving/purging data, and initiating the test.

Kinda figured that this would be a V2.0 discussion, but the advantage is that any development done on such a system would pay off with web based control for any other projects, spooling them up with a polished interface within days or weeks instead of months or years. I lean hard toward the Bone, but I didn't want my prejudice on the subject to flavor this discussion. Even aside from the supply issues, the Pi has 1 I2C bus, 2SPI, a UART and 8 GPIO pins as opposed to the Bone with 2 I2C, 5 UART (which can be configured as I2C, SPI, CAN or serial), 7 ADC channels, and 66 3.3V GPIO. While I recommend the Pi for middle and high school education, the Bone is kind of a no-brainer for serious applications as far as I am concerned.

The other thing I was thinking about for version 2.0 is moving toward a much smaller 3D printed frame using linear bearings on short shafts for the test carriage. With a 3D printed solution we could put all the sensors on the carriage; the temp sensors on a small PC board mount below the motor mount and the FSR mounts to the nose where the motor drives the carriage into the end stop. Communication between the sensor board and the Bone could be as simple as IRDA on as UART channel. This design would be tiny... overall length only a couple of inches longer than the engine under test, 4" tall, and 6" wide to accommodate the bone with some protection. A minimalist design like this would solve a few issues, but would require a different method to secure the test stand to the ground.

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

Hi Ben,

While I would see the wisdom of going the whole range to destructive, the trouble is that sensors which can withstand both the forces and temperatures of the event would be massive and thus have a slow slew rate. The other issue is that during a burn through event, due to the pressures and temperatures involved, the event would happen incredibly fast. I figure it is more important to get the data leading up to the destructive event at the highest possible resolution rather than record the whole thing. Anything designed with a safety margin like what I would expect from a rocket engine sold to minors would have at least a 200% redundancy, so the 50% would measure the full scale of what was expected as well as show the trends just before things went south.

Best,

Aaron

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

My thought was that there would be no Ethernet interface at all on the Arduino or MSP430. The Arduino would dump its data over serial to the laptop, and then the laptop would handle serving that data out to multiple clients through websockets or something similar. The Arduino is completely isolated from the clients. I agree with you though that if you try to make the Arduino the web server that you're asking for trouble.

I'm with you on all the interfaces except the one to initiate the test. It's hard enough for me to trust that to a C++ app running on a laptop connected over USB/serial, let alone something that has to communicate back through a web server to the microcontroller. Anything where reliability is key should probably be more directly connected, in my opinion. Do you disagree Aaron?

I've got some thoughts on the mechanical design for 2.0 too, and I'm looking forward to hashing through all our thoughts and coming up with something really solid. I'm not sure I have the bandwidth for that yet though.

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

The only way I would trust a web interface for something like this is to have a mechanical interlock or safety pin and a buzzer to indicate that the unit is attempting to fire while the pin is in or interlock is disabling the firing circuit. This would give us two layers of physical security in addition to the security of the interface and page login. That said, this would not be that hard to implement.

I don't really have the bandwidth for that discussion either, so no worries. Perhaps such a discussion would also be better suited to moving forward with Glenn anyway.

RE: Future Design Discussion - v2.0 - Added by Ben Barnett almost 11 years ago

Aaron Harper wrote:

Hi Ben,

While I would see the wisdom of going the whole range to destructive, the trouble is that sensors which can withstand both the forces and temperatures of the event would be massive and thus have a slow slew rate. The other issue is that during a burn through event, due to the pressures and temperatures involved, the event would happen incredibly fast. I figure it is more important to get the data leading up to the destructive event at the highest possible resolution rather than record the whole thing. Anything designed with a safety margin like what I would expect from a rocket engine sold to minors would have at least a 200% redundancy, so the 50% would measure the full scale of what was expected as well as show the trends just before things went south.

Best,

Aaron

Hi Aaron,

OK, point taken. To eliminate the arbitrary nature of temperature scales, the "50%" part of 2. should read: "...50% of the difference between the expected ambient temperature and the temperature at which the case would be damaged or destroyed..."

With regard to the speed and resolution issues, fine-wire thermocouples are fast, and small bead thermistors have much higher resolution, with only a slight penalty in speed. For small bead thermistors see:
http://www.meas-spec.com/downloads/Miniature_Radial_Glass_Thermistor_Series.pdf
http://www.redfishsensors.com/PDFs/VECO%20PICO%20BEAD.pdf
http://www.sensorsci.com/index.php?option=com_content&view=article&id=14&Itemid=23
It looks like "redfishsensors" has picked up the VECO line from Meas-Spec, and "sensorsci" has picked up the Thermometrics line from GE. The thermistor market that I knew so well just 6 years ago is all different now. Note that the small bead thermistors, like fine thermocouples, are NOT electrically isolated. In most cases, high speed temperature sensors are attached to the D-U-T so intimately that they must be considered disposable. Less intimate attachment means much slower response. Another note: Teflon is about useless as electrical insulation with fast temperature sensors because its thermal mass is close to that of aluminum (high) while its thermal conductivity is about 1/1000 that of aluminum (low) = long time constant.

Hope this is useful,
Ben

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

We're currently in a situation where version 1.1 is not completely finished, but we're needing to work on version 2.0 ASAP due to what might become a hard deadline. We have a partner organization that has named Mach 30 on a NASA grant. If they are awarded that grant, we will be required to provide them with between 5 and 10 Shepard v2.0 kits by Q4 2013 or Q1 2014. Since we have a small team on this project with Aaron and I being the only DAQ hardware builders, we need to make sure that we have enough time to have the kits designed, built, and thoroughly tested by then. I believe that this is going to require stopping version 1.1, documenting it to the point it's at, and noting why the version is being stopped.

After some discussions with Aaron, and considering some input in the past from Ben, here are some items I'm looking at purchasing to experiment with for version 2.0. None of these prices include shipping.

Needed for project:
1. Next Gen BeagleBone: $45 - http://www.adafruit.com/products/1278
2. BeagleBone Proto Cape Kit: $9.95 - http://www.adafruit.com/products/572
3. 5 Kg Load Cell: $6.80 - http://www.robotshop.com/micro-load-cell-5-kg-2.html
4. Non-contact temperature sensor: $3.94 - http://www.newark.com/texas-instruments/tmp006aiyzft/ic-infared-thermopile-sensor-14bit/dp/48T2174?CMP=AFC-JY6146109556
5. 12-bit ADC (SPI interface): $11.81 (x2) - http://www.ti.com/product/tlc2555

Purchased by Jeremy for convenience:
1. Beagle Bone proto plate: $7.95 - http://www.adafruit.com/product/702

Any thoughts on this? Anything to add Aaron?

RE: Future Design Discussion - v2.0 - Added by J. Simmons almost 11 years ago

Jeremy,

I concur with the move to close out v1.1. In the time since we proposed that version too many things have changed in the DAQ design for it to teach us any more lessons than we have already learned. Note, I think we need to make sure we capture any costs associated with v1.1 components as Mach 30 expenses (there is a line item for v1.1 in the budget, this is just making sure we dot our i's and cross our t's with the expense reports, etc).

I do have a couple of questions concerning the experimental parts list. Can you tell me more about the non-contact temp sensor and the 12bit ADC? When I went to look at the temp sensor, it looked like it only reads up to 125C. I forget, is that enough for the case temperature we expect to see (with some room for out of range runs)? And, which sensor(s) will be hooked up to the ADC?

Just one more detail, it looks like these experimental parts will cost around $86+shipping (so call it around $100 or so) out of the budget of $200 for the v2.0 DAQ design and testing. Do folks feel comfortable enough with the larger ticket items that we should expect to stay on budget for the v2.0 DAQ?

Thanks Jeremy and Aaron for getting this going.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

J,

The NAR testing guidelines outline the following in section 8.6:

"The external casing temperature will be measured on at least one motor of a given type during initial certification testing, to ensure that this temperature does not exceed 200°C during or after firing, as required by NFPA 1125."

So, we are a somewhat below the range that the NAR testing and standards group cares about. If the casing temp exceeds 200°C, it sounds like they consider it to be a failed motor. We need to decide if that's a deal breaker that we're 75° below. Good catch J. I hadn't looked carefully enough at the specs yet. Aaron, have you seen any of that type of temp sensor with a 200°C max or more?

I think I may have made a mistake on the ADC. We should only need one ADC for just the thrust sensor since the non-contact temp sensor has it's own serial interface. In that case, the cost would drop to around $78 plus shipping.

With the structural designs that we've unofficially discussed for version 2.0, I feel like we could come in on budget to $20 or so over.

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

First, Jeremy you are correct that the temp sensor has it's own pre-calibrated ADC and serial interface. This simplifies things a great deal eliminating instrumentation amps and ADCs for each sensor and the calibration necessary.

While I would agree with NAR that 200C is a failed motor, I get the feeling that it is more important to see the rate of rise on the motor's surface than to go all the way to 200C. I will continue to look around for a 200C sensor, but that is what we have at the moment. The nice thing is that with a serial interface which reads directly, all we have to do is change out the sensor and the board it is on. I should also point out that this type of sensor will be one to play with of HAB and Satellite projects, since it reads thermal radiation of an object directly; it requires neither air or contact to work. Designed to measure the temp of CPUs in laptops and communications gear, the price is in the basement ($3.94 with free prototyping samples) compared to similar devices due to production volume... but this also has defined its range of measurement.

Finally, the TI TLC2555 ADC is needed specifically for the load cell sensor, and only one is needed for the test stand.

RE: Future Design Discussion - v2.0 - Added by J. Simmons almost 11 years ago

Hey guys,

Thanks for the clarifications. Those helped a lot. It sounds to me like we should spend maybe one more day looking for a wider range temp sensor just to see if one can be easily found. If not, $4.00 for a test unit to experiment with sounds like a good deal, and an easily affordable expense to see how this class of sensor works for us.

Also, just a side note, the DAQ, mechanical, and kitification steps each have their own $200 budget this year (they are in some ways separate "kites" leading up to the Shepard kit). Based on Jeremy's post, it sounds like we should have plenty of budget left after this round of experimentation to address any lessons learned with another iteration of the DAQ if necessary.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

J - We're still shooting for $200 material cost on the Shepard 2.x test stand design that gets kitted though, right? It's my understanding that the kitting costs, labor, etc will be above and beyond that.

RE: Future Design Discussion - v2.0 - Added by J. Simmons almost 11 years ago

Yes (per the estimates used to put together our part of the NASA grant application). So, to just get everything budget wise all in one place.

  • Target cost for Shepard kit materials: $200
  • v2.0 DAQ kite budget: $200 (allows for some experimentation leading up to final design and shipping of components)
  • v2.0 Structure: $200 (allows for some experimentation leading up to final design and shipping of components)
  • v2.0 Kit development: $200 (guessing this will be used to cover materials for a complete kit build based on development of DAQ and structure)
  • v1.1 components: $50 (covers cost of parts ordered for the testing and building of v1.1)
  • v1.0 repairs: $25 (replacement parts for the motor mount we blew up at Ft Wayne Maker Faire)

That all jive with people's expectations/understanding?

Sources:

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

I've researched the infrared thermopile sensors some, and while I didn't find any that would go over 125 C, I did find this:

http://www.adafruit.com/products/1296

It's $20, but it would allow us to test the TMP006 quickly without the painful soldering/reflowing of the TMP006's tiny package. It would also make the Shepard kit easier for anyone to assemble, while driving up the cost only a little bit by the time you factor in the labor and materials to build a breakout board ourselves.

If I don't hear anything to the negative, I will probably try to get the first wave of components for testing on order this evening. After that, I'll keep all of my work in dev logs through ODE's news feature until we have enough information to tell if our ideas are going to pan out for the final design.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

There's also this for the DIY angle.

http://dangerousprototypes.com/docs/Marie_:_Infrared_Thermopile_sensor

We still need to figure out the break even point between our labor and materials vs just buying the thing already finished from somewhere like Adafruit though.

RE: Future Design Discussion - v2.0 - Added by J. Simmons almost 11 years ago

Jeremy,

First, in general, I am good with ordering the first wave of parts for testing, with the possible exception of the temp sensor. Which takes me to my second point, which is to admit, I am still a little lost about the temp sensor. Does ordering the $4 part in the post with the original list of parts mean we have to do a bunch of reflow soldering? If so, I am not sure even at $4 it is such a good buy given our current fabrication constraints. But, the Adafruit part seems to be a little too expensive for a sensor which we know does not have nearly enough operating range.

How about we focus on the force sensing fir this first round of testing (after all, this involves a new sensor type and a new DAQ board, so we have plenty of things to work out during the testing right now already)? And then continue researching temp sensors for something which will meet our needs range, response, integration, and cost wise.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

It's going to be very hard (if not impossible) to get away from having to reflow at least something for this version of Shepard. As the functionality of Shepard becomes more sophisticated, the selection of ICs gets more sophisticated with smaller and harder to solder packages.

To get meaningful temperature information I think we've decided here on the forums that thermocouples will probably not cut it due to their slower response times. To get useful temperature profile information, we'll probably have to go with a highly responsive IR temperature sensor (like the TMP006). This Phidgets sensor has a range of -70C to 380C, so maybe we can research what sensor it uses.

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

As Jeremy noted, it's hard to get away from integration as the complexity of Shepard goes up, but there is another factor. Non-SMD parts, particularly ICs are getting scarce as vendors retire old designs and don't bother to make a DIP version of their new device. I detest working with the small stuff, particularly the BGAs like the thermopile, but it is what it is. Another reason they do it, is that as measurements come closer to RF frequencies, the leads for thru-hole components can act like antennas causing, or receiving interference.

Now, if our budget will allow for $25.00 for both temp sensors, I have found just the thing: http://www.melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/MLX90614-615.aspx This sensor is available at Digikey for $12.49 and Future Electronics for $9.17 in single quantities.

It has a digital (SmBus which is I2C compatible) output meaning that it needs no calibration and has a range of -70 to 380C (it's the same sensor as the Phidgits module without the shroud). Best yet, it's a 4 pin through-hole TO-39 can that we all can solder without going blind!

While I see the wisdom of holding off on the temperature measurement for this reason and to avoid too much change, I must point out that this would be the second time we walk away from a design criteria on Shepard, and in the same area. Changes would be pretty much across the board in the data system anyway due to the different controller... we might as well do a complete redesign with little more work and get everything we want.

RE: Future Design Discussion - v2.0 - Added by J. Simmons almost 11 years ago

Just a couple of quick comments. First, this latest sensor looks very promising. If everyone else is good with ordering it, I would be as well.

Second, I want to clarify that I was not proposing that we drop the temp sensor from the v2.0 design work, merely that we not let spec'ing the temp sensor hold up ordering the other components we already knew we wanted. It was starting to sound like we may need considerably more time to find the right temp sensor, and since there was plenty of work to be done with the new board and thrust sensor, I would have hated to see us loose testing time because we hadn't found a temp sensor we could use yet.

Thanks for all the hard work!

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

I believe this latest sensor is exactly what the doctor ordered. The only gotcha is that we will need to create an aperture in the motor mount for each sensor so that it can read the surface temp, and each sensor needs to be shrouded so that it will only read the motor casing, not the exhaust plume or frame.

With this, I believe our sensor suite is complete with all specified measurements made at an accuracy and speed higher than what is needed, and with the types of technology necessary for development of future versions. Bottom line: Nothing is orphaned, especially the experience and coding.

1 2 Next » (1-25/30)