元スレ【宇宙開発】ＪＡＸＡ、名大と開発したトロン準拠ＯＳをＨ２Ｂロケットに搭載

宇宙天文news覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

52 :

あれ？前からトロンじゃなかったっけ？
はやぶさもOSがトロンとか聞いたけど？

53 :

ウインドウズはＧＭ車の乗り心地。そのドン臭さにいらつくたびに、
もしトロンが世の中にもっと出ていてくれていれば、トヨタ車並みの
快適さだったはずと思う。

55 = 35 :

>>41
デジタル録画やら複雑な制御やらで対象の規模が大きくなってきたんで、
iTRONもだんだんLinuxやリアルタイムLinuxに切り替わってるよ。

58 :

>>11
一枚噛んだと言われる禿糞朝鮮人は取り敢えず死ねと

59 = 48 :

今のJAXAの軌道設計では実数2,000桁以上、3000桁などと言われているぞ。
リアルタイムで2,000桁以上を扱えよ。

60 = 48 :

あのハゲ爺は岐阜県民だと言われているからな。

61 :

>>50
価格が高すぎだろ、あのOS

62 :

TRONもLINUXに置き換わって役目を終えつつあるって感じだけど
どうなんだろうね

63 = 35 :

>>54 >>57
有効桁数？

それは管制の領域で、実機のリアルタイム制御には
関係ない気がするんだけどなあ。
燃料バルブや姿勢制御でそこまで精度要るんだろうか。

66 :

>>56
コムデギャルソンとかパパスとかメンズメルローズとかそういうやつ。

69 :

ウィンドウズはビジネスモデルで勝ったんだよ。だいたい米企業はそれで勝つ

70 = 48 :

処理速度を上げるためにチップを分けて扱う場合はHAL形式か？
初期のスペースシャトルでは3つだったが、コンステでは5つだったか？
帯域が増えれば全部送受信すればいいんだけどな。
そのためにはオシレータの分解能がいるんだろ？
オシレータの桁数がいるわけだ。何桁？

71 = 48 :

オシレータの表現可能桁数は、同一指標のオシレータの生産数に置き換えられるわけだ。
どうどう巡りだな。ppt？

・・・ここで中国依存だろ？めんどくさ。自国内でもやれよ。
Windowsの罠であるNTP依存も、現状ではナノセカンド止まりだからな。
調整項目が多い。

72 = 48 :

内部分解能を上げるとミスしにくい上に、移動速度も増せるしさらに詳細制御が可能になるはず。
高級品であることをアピールするようなものだ。
ダイソー手提げ袋とＬＶバッグの違いみたいなものだ。
もちろんデータ送受信上で処理が追いつく桁数である必要がある。
データを切り取ってしまうと無駄な処理になってしまうからな。
各制御部分を担当していて、参考とする入力データの桁数が足りないなんてありきたりだろ？
テレメトリとか言って誤魔化しかねない部分だな。
そういうのを回避するためでもあるはず。
通常は全うするべき桁数と、目標とするべき桁数と、よそで達成されており、一般的に指標となる桁数があるのでは？

74 = 48 :

チップ性能が高ければ内部圧縮して別チップで内部解凍するんだろ？
同じ処理を通信上でも行うんじゃないの？
16進圧縮に限らないだろ？時間軸側で圧縮でも5次元でも6次元でも圧縮すればいいのでは？
通常では複数項目を合わせて圧縮する程度じゃないの？
単一項目上で桁数が増えるとその分、圧縮率が上がるのでは？

チップのピン数を増やせという話にしかならないなｗｗｗ

76 = 48 :

しかし計算速度なんて、内部で持っているコンスタント値の種類と桁数が重要だよな？
一般的に何種類くらいの項目を持っているんだろうか？
当然、全て2進化された値だろうけれども。
piみたいに、あるだけ長大桁で開示すればいいのに。あくまで検証用だけどな。
√2から√2000まで、全部を実数で2,000桁まで計算すると何秒？
普通は特に割り算傾向の計算は事前に計算しておき、実数データで持つわけだ。
計算を効率化すれば実数データから持ってくるより速いかも？
しかし開発に時間が掛かるかも？
√20に対し√2000は10倍でしかないよな？
√20の実数を10倍するのと√2000の実数を引っ張ってくるのとではどちらが速いか？
多分一般的には実数を引っ張ってくるほうが速い。
「√2000なんて使うのか使わないのか？」と言われても、「あれば使える」としか言いようが無い。
発想が貧困なのでコンスタント化できそうな全ての関数が出てこないがｗｗｗ

77 = 44 :

TRONはカーネルだからLinuxもアンドロイドのカーネルになるけど
速さではTRONが一番だからユビキタス社会ではTRONの上にさまざまなＯＳが
乗っかる形になる。
ソフト開発者やユーザーの多さからLinuxやアンドロイドはそのまま残した
ほうがいい、日本はロケットも衛星も自前で飛ばせるしＴＲＯＮの開発元
なんだから余計なＯＳをいれず全部国産で開発したほうがよい、それがJAXAの判断。
省エネでリアルタイムでコードも全部わかるＴＲＯＮはこれほど
宇宙開発むけなＯＳはない。

78 = 48 :

チップは冷却でどこまででもクロックを上げられると言われるが、さて？
通常利用でも窒素冷却程度で6GHzあたりの2倍程度のクロックには堪えたという話も昔の話。
今度は冷却制御で一定温度範囲内を精密に保つロジックの方向なんじゃないの？

79 :

実身、仮身 …

80 :

トロンの木馬って奴か

82 :

TRONて、潰されるとか消えるとかいろいろ言われながらも
しぶとく今まで生き残ってるのが凄いな。
よっぽど実用性が高いんだろうな。

83 :

実際、末端の小規模組み込み機器を動かすのにはμITRON最強だろうて

84 = 48 :

チップ装置を燃料供給装置付近に置くと、冷却触媒が循環する上に冷却もできるんだろ？
そもそもそうしているんじゃないの？
そうなるとTHzでもPHzでもお好きなように、と言われかねないなｗｗｗ

86 = 48 :

VC++ではclockのCLOCKS_PER_SEC指定で分解能的にオシレータ依存のクロック表示が一般的らしいね。細かさは謎。
PHPにも一般開示された指標項目でnanosleepはあるな。
普通はクロックカウンタの分解能もカウンタの2進桁数で扱っていそうだな。
最小単位の1カウントアップ時間と、実時間の差の計測と平均化とさらにその誤差の縮小だよな？
結果的に地球上などで強制冷却で試験せざるを得ないような気がするぞ。
「基準となる設定温度を1℃下げるとどの程度時間分解精度が増すのか？」
さらに「その際の温度分解能は？」という話だろ？
これで未来に限界が見えるので、あまり温度を下げたがらないんじゃないの？
しかしK値の分解能も結局無限だろ？

・・・分析も飽きた。早くやって情報開示してよ。
その際のHz数の桁数をどうするのか？なんて話があるけれども。
ウィンテルに無理に気を使わなければ、どこまでも上げればいいという話になるな。

87 :

今北ニワカでスマンが
トロンって昔日本がOS開発始めて良い所に行きそうになったら当時独自開発しようとした戦闘機のF-2同様に雨が潰しに掛かりその時は日の目を見なかったけど
今日世界中で日本製のデジカメビデオが広まってるのはとうじのトロンの技術を応用し、ドコの国も真似できないから

との認識でOK？

88 :

>>87
間違ってる。

そもそも日本でも本気で普及させようと思ってたのは一部だけだし、
その一部にしても口ばっかで具体的なものは何もできていなかった。
ドタバタしてるうちに他が先を行過ぎて太刀打ちできなくなっただけ。

こういう組み込み分野ではTRONは普及しているが、それも最近は
Linuxやらに押され気味な印象。
ただそれは組み込み分野がPCに近づいてきたのが原因なので、
場所によってはまだ適材適所なものはある。

89 :

全然違います。

91 = 48 :

CCSDSにしろ、そもそも文章量が多いので、自動翻訳させないとわずらわしいんじゃないのか？
自動翻訳しても翻訳結果の補正が必要なはずなので句点ごとに分けられ、辞書項目と対比しやすいような翻訳支援ツールが要る。
Googleのツールに翻訳支援とかがあるが、あれは動作が遅いな。
英文120ページ程度で動作がおもいきりもたついてしまう。
原文を分割しないと使えたものじゃない可能性が高い。

結局、なぜ宇宙開発関連の外国語文書を母国語への翻訳し結果を開示しないのか？が気になる。
CCSDSもあくまで桁数指標や項目などを提示するためのフォーマットなので、さっさと開示してフォーマット内容を議論すればよかろう？
そういったことすらしないで指標よりも桁数が足りないなどという愚挙が出たら、やるべきことをサボった弊害であるとしか言いようが無い。

93 :

なぜ犬なんだ？と思った俺はいまエアコンのスイッチを入れた

94 :

じゃあ、イプシロンでやってる
ノートPCでモバイル管制　みたいなのは、リナックスになってる可能性あるってことか

95 :

Guiは必要ないし、安定性と軽さ重視
当然だろ
TRONは家電も多いよな

98 :

無償で使ってると宣伝とか入ったりするんでしょ

100 = 48 :

早く作れよ。搭載できないじゃないか。