Mach 30 #EngineeringSpeak Hangout August 01, 2013

Discussion Topic:  Work on Shepard

Attending: Aaron, Chris, Greg, Jeremy, Juli, J,

Start:  22:15 EDT

End: 23:30 EDT

Minutes:

• Jeremy - has list of questions to address
• Jeremy - safety radius when firing E motors (NAR lists radius for launch with E motors as 30’), but we would like to go down to 15’

• Greg - can you explain the reason for 15’?
• Jeremy - our connection to the DAQ (arduino) is USB, and the max length for USB cables is 13’ (can get to 15’, but not 30’ without going upgrading connection)
• Aaron - what about logging data on arduino?
• Jeremy - would need data collecting shield, and that is about $60
• Greg - can’t we just put another cable extension?
• Chris - that would slow the data down in all likelihood
• Chris - alternatively, we could go with an extender (a powered device that extends USB range), but they cost about $40, which is close to what upgraded capability would handle
• J - note, the launch controllers we have been using are also 15’ radius, so would recommend switching this from a technical issue to a procedural one; accept 15’ radius and then do one of two things; either do the required research to show that static firings do not need the 30’ safety radius compared to launching with E motors, or limit to D motors as max
• Aaron - what about building our own launch control circuit?
• Greg - pretty sure the extra radius is for potential of E motor powered rocket to go further if it does not fly vertically (based on the motor performance curves - http://www2.estesrockets.com/pdf/Estes_Time-Thrust_Curves.pdf)
• Chris - Is there anything we can do to in the safety protocol to cover our liability (like recommending they consider extending the range for E’s)?
• Aaron - What about a two stage approach to the problem? Initially, limit design to a D sized motor, and once it is confirmed that the safety radius can be reduced, increase the mount size

• J - then log this as an issue in ODE

• Greg - safety protocols may need to take into account the skill level (and maybe age) of the builders and the operators
• J - it may be time to build a safety cage into the design?  This would be to address any concerns about the motor coming loose and land sharking
• Greg - not sure we are there yet in terms of safety concerns

• Jeremy - next question, deciding on whether to stay with Processing as the devel language for the desktop app

• Jeremy - many arduino projects use Processing for computer side apps mated to arduino projects (like “peanut butter and jelly”)
• Aaron - what are pros and cons of each option?
• Jeremy - pros for processing

• we already have a code base
• arduino community preference for Processing
• the Processing IDE is the base for the arduino IDE, so familiarity with one gives you familiarity with the other
• J heard at New Space that educators are getting more experience in arduino than other embedded systems (so by extension would most likely see Processing over other languages)

• Jeremy - cons for processing

• the GUI library is not great (we will need to extend it in places)
• there are java version issues
• other languages like python are more mature for GUI development and most of this app is GUI

• Aaron - talking about the language for the desktop app?
• Jeremy - yes
• Greg - how does this relate to meeting requirements?  Is this requirements creep?
• Jeremy - well, yes/no?  If processing is too hard to make the test stand reliable enough for outside users to actually run the test stand, then it fails basic operation capability
• Greg - so how polished does it need to be?
• Chris - thinks Shepard is more for educational use than development, and later test stands are more for development
• Aaron - ditto
• J - Do the penalties for using Processing outweigh the pros of staying in step with the Arduino/Processing community and being set up for educational uses.

• Chris - Not enough benefit in this.

• Chris - What about using the Arduino Ethernet shield and taking care of the safety radius and communication channel in one.

• J - Worried about making it too hard for educators to use.
• Aaron - We do have to be able to pass the “grandma test”, but educators need to be able to pop the hood as well. Doing something like a custom layer 2 interface doesn’t fit that.
• Chris - There seems to be a bit too much setup involved with the current Ethernet shield, meaning that it wouldn’t pass the ‘Grandma’ test

• J - Python? If Jeremy can reproduce what we have in 10 days, Python may be the better way to go.
• Chris - if this (http://playground.arduino.cc/interfacing/python) works, on board with this plan (not a fan of Processing, and not seeing it grow as a language)