|11 Jul 2018|
|23:48:30||yalda changed the history visibility to "world_readable" from "shared".|
|13 Jul 2018|
|18:57:19||sean changed their display name from drbriefs to sean.|
|18:57:43||sean changed their profile picture.|
|23 Jul 2018|
|07:13:38||yalda changed the room name to "SD-Development" from "SD-Building Blocks".|
|07:18:42||yalda changed their profile picture.|
|24 Jul 2018|
|09:46:11||yalda changed the room topic to "Enhancing spacedecentral.net and developing enabling technologies." from "Enhancing spacedecentral.net and developing enabling technologies. Contribute to program on https://github.com/spacedecentral/building-blocks/".|
|25 Jul 2018|
|13:18:50||mikro2nd joined the room.|
|13:28:25||mikro2nd set a profile picture.|
|31 Jul 2018|
|05:00:31||outbound changed their profile picture.|
|1 Aug 2018|
|23:20:15||tmallard joined the room.|
|2 Aug 2018|
|06:52:51||schorgie30 joined the room.|
|26 Aug 2018|
|00:00:51||sean invited neutronstar.|
|04:33:58||neutronstar joined the room.|
|07:17:01||neutronstar||Discussions in this room has so far centered around more high-level stuff, web-site and collaboration tools. I personally am a more low-level stuff. I'd love to get my hands dirty when it comes to software that will be in whatever we send into space/moon. Is there interest in discussions about choice of OS, how the development process should look like, how to manage use cases and requirements, how designs should be described and so on?|
neutronstar: nothing that low-level as of yet, though you're more than welcome to get the conversation started! Are there any design constraints that come to mind that could help narrow down such options? I haven't had the luxury to investigate embedded level hardware or software options yet, but I'd imagine RAD750 may come up as a viable FCU solution, if/when we ever do such a trade study, considering it's NASA's current state of the art as far as space-grade flight computers go.
Regarding development process, at the highest level, we have the SMAP process, which is for selecting and defining high-level mission concepts (https://medium.com/spacedecentral/space-mission-activation-process-c6e7c2a0910f); on a systems engineering level, there're (WIP) plans to adopt an implementation of the model-based systems engineering methodology, using the Systems Modeling Language (SysML), which would serve as an interface between high-level mission & system level requirements and lower level system & software requirements, support verification & validation processes, lifecycle analysis, multi-disciplinary analysis & optimization (MDAO), and various other activities (see https://docs.google.com/presentation/d/1cvZYfUS3MYQZ0omOebTGaFulYbIOccHG89cxApIolCs/edit#); development process on the lowest-level (embedded) side is virtually non-existent at the moment, as we're still discussing whether the development of space-hardware itself should fall within the scope of the space decentral community - though, for context, we're also quite short staffed on systems engineers and embedded-hardware/software developers.
I should also mention a subset of the space decentral team are also working on blockchain apps that we plan on adopting as part of our platform to support governance and agile planning activities (https://medium.com/giveth/space-decentral-the-dao-for-space-exploration-2af372d310af). Last, but not least, there's of course the http://spacedecentral.net web platform itself, which is concurrently being enhanced alongside our other open-source projects.
My space decentral compadres can correct me or append to anything I may've missed, but hopefully that was descriptive or helpful enough (if not, please don't hesitate to ask more questions)!
|19:15:49||neutronstar||I'm not familiar with how model based systems engineering works, but I would love to learn more. I've heard about it before and it is one of those things that I have on my list that I should learn. I'll take a look at it. My concern is how to map use cases to requirements, requirements to design/implementation requirements, and design/implementation requirements to actual code. Doing this manually doesn't work well in my experience, tools that tracks this automatically is needed. Would model based systems engineering help with this?|
Yes, though at least that's what it intends. The most widely used implementation of the model-based systems engineering (MBSE) methodology is language called SysML, which is an extension of a subset of UML, which models systems into 3-5 "pillars" (depending on which source you consult):
Without getting too much into detail, I've been working on a python implementation of SysML (see https://github.com/spacedecentral/SysML.py) to try and address shortcomings of the current MBSE tools. Reasons for why I chose python are outlined in the link above, but it would essentially be an interface for verifying and validating system requirements and their transcription to flight hardware/software - note: this use case is still a work-in-progress, so would love to get your feedback on the best way to implement this!
|6 Sep 2018|
|05:49:57||erik changed their display name from erikkulu to erik.|
|18 Sep 2018|
|19:03:30||neutronstar||Realized that my message in the mission room regarding what electronics to use should have been in this room, sorry for that. Feel free to comment my message here instead!|
In reply to @neutronstar:matrix.orgCare to repost for context?
Ok, here is the repost:
Being an embedded developer, I couldn't resist the urge to look on what electronics that we might use. I've read up a bit on how to secure electronics against radiation and what electronics that might be bought off the shelf. After much consideration I've come to the conclusion that we can skip special radiation hardened electronics, except perhaps for some special smaller application. I would instead propose to use a number of smaller cheaper single board computers and use them in a voting and/or load balancing configuration. One suggestion below, costs 5$ each:
We need some I/O board to interface motors and sensors, and perhaps some voting hardware.
Any thoughts on this?
|19:21:59||sean||There's a MIL spec somewhere (I'll try and look for it) that's often referred to for qualifying space grade hardware. It might be overkill for our applications, but it might give us some set of constraints to work with.|
The problem with electronics adhering to military or space standards is not only costs, but also ITAR. This basically means no development outside USA for an open-source project, and even within USA there might be a bunch of rules to follow. A lot of hassle. Unless I've misunderstood something...
The exception would be if we found hardware from outside USA, but then it could be ITAR classified as soon as it reaches the borders.
So this is the reason I propose to use standard components. But we could of course improve it using good casing etc.
|21 Sep 2018|
|14:32:17||mhpanda joined the room.|
|1 Oct 2018|
|20:04:21||danktron joined the room.|
|12 Oct 2018|
|23:47:28||greg.g joined the room.|
|19 Oct 2018|
|22:36:30||pete.b joined the room.|
|16 Nov 2018|
|20:06:41||grouchofractal joined the room.|
|28 Nov 2018|
|15:31:24||theobtl joined the room.|
|12 Dec 2018|
|14:39:18||@lkngtn:matrix.org left the room.|