2 research outputs found

    Autonomous Restructuring of Asteroids into Rotating Space Stations

    Full text link
    Asteroid restructuring uses robotics, self replication, and mechanical automatons to autonomously restructure an asteroid into a large rotating space station. The restructuring process makes structures from asteroid oxide materials; uses productive self-replication to make replicators, helpers, and products; and creates a multiple floor station to support a large population. In an example simulation, it takes 12 years to autonomously restructure a large asteroid into the space station. This is accomplished with a single rocket launch. The single payload contains a base station, 4 robots (spiders), and a modest set of supplies. Our simulation creates 3000 spiders and over 23,500 other pieces of equipment. Only the base station and spiders (replicators) have advanced microprocessors and algorithms. These represent 21st century technologies created and trans-ported from Earth. The equipment and tools are built using in-situ materials and represent 18th or 19th century technologies. The equipment and tools (helpers) have simple mechanical programs to perform repetitive tasks. The resulting example station would be a rotating framework almost 5 kilometers in diameter. Once completed, it could support a population of over 700,000 people. Many researchers identify the high launch costs, the harsh space environment, and the lack of gravity as the key obstacles hindering the development of space stations. The single probe addresses the high launch cost. The autonomous construction eliminates the harsh space environment for construction crews. The completed rotating station provides radiation protection and centripetal gravity for the first work crews and colonists.Comment: 65 pages, 53 figures, 25 tables; Version 2 includes editorial changes, improved dumbbell stability details, and reference updates and addition

    Gerenciamento explícito de memória auxiliar a partir de arquivos-objeto para melhoria da eficiência energética de sistemas embarcados

    Get PDF
    Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós-Graduação em Ciência da Computação, Florianópolis, 2010Memórias de rascunho (Scratchpad Memories - SPM) tornaram-se populares em sistemas embarcados por conta de sua eficiência energética. A literatura sobre SPMs parece indicar que a alteração dinâmica de seu conteúdo suplanta a alocação estática. Embora técnicas overlay-based (OVB) operando em nível de código-fonte possam beneficiar-se de múltiplos hot spots para uma maior economia de energia, elas não conseguem explorar elementos de programa oriundos de bibliotecas. Entretanto, quando operam diretamente em binários, as abordagens OVB conduzem a uma menor economia, frequentemente exigem hardware dedicado e às vezes impossibilitam a alocação de dados. Por outro lado, a economia de energia reportada por todas as técnicas, até o momento, ignora o fato de que, em sistemas que possuem caches, estas deverão ser otimizadas antes da alocação para SPM. Este trabalho mostra evidência experimental de que, quando métodos non-overlay-based (NOB) são utilizados para manipulação de arquivos binários, a economia de energia em memória, por conta da alocação em SPM, varia entre 15% a 33%, e média, e é tão boa ou melhor do que a economia reportada para abordagens OVB que operam sobre binários. Como esta economia (ao contrário dos trabalhos correlatos) foi medida após o ajuste-fino das caches - quando existe menos espaço para otimização -, estes resultados estimulam o uso de métodos NOB, mais simples, para a construção de alocadores capazes de considerar elementos de bibliotecas e que não dependam de hardware especializado. Este trabalho também mostra que, dada uma capacidade CT de uma cache pré-ajustada equivalente, o tamanho ótimo de SPM reside em [CT//2, CT] para 85% dos programas avaliados. Finalmente, mostram-se evidências contra-intuitivas de que, mesmo para arquiteturas baseadas em cache contendo SPMs pequenas, é preferível utilizar-se a granularidade de procedimentos à de blocos básicos, exceto em algumas poucas aplicações que combinam elementos frequentemente acessados e taxas de faltas relativamente altas
    corecore