บันทึกการสร้างแท่นยึดกล้องดูดาวด้วยฮาร์มอนิกไดรฟ์แบบคัสตอมและ ESP32

• ผู้เขียนสร้างแท่นยึดกล้องดูดาวแบบคัสตอมโดยใช้ ฮาร์มอนิกไดรฟ์ (harmonic drive) และ ไมโครคอนโทรลเลอร์ ESP32
• เนื่องจาก แท่นติดตามเชิงพาณิชย์ ที่มีอยู่เดิมมีราคาสูงมาก จึงเลือกออกแบบและสร้างเองแบบ DIY
• อธิบายกระบวนการออกแบบทั้งหมดอย่างละเอียด ตั้งแต่ การออกแบบและผลิต PCB, การทำโมเดล 3D ด้วย FreeCAD ไปจนถึงการคัดเลือกชิ้นส่วนประกอบ
• ต้นทุนรวมในการผลิตอยู่ที่ราว 1,700 ยูโร และเมื่อคำนวณเป็นต้นทุนต่อ 1 เครื่อง ก็ยัง แข่งขันกับผลิตภัณฑ์เชิงพาณิชย์ได้
• แชร์ประสบการณ์ด้านประสิทธิภาพการถ่ายภาพดาราศาสตร์จริงและการปรับปรุงต่าง ๆ ผ่านการผสานแท่นที่สร้างเองเข้ากับ เฟิร์มแวร์ OnStepX

---

จุดเริ่มต้นใหม่

เมื่อหลายปีก่อน ผู้เขียนได้รับแรงบันดาลใจจาก ช่อง YouTube เกี่ยวกับการถ่ายภาพดาราศาสตร์ จนเริ่มสนใจงานอดิเรกนี้ โดยลองถ่ายเนบิวลานายพรานด้วยวิธีถ่ายภาพหลายร้อยใบด้วยเวลารับแสงสั้น ๆ บนขาตั้งกล้อง แล้วนำไปซ้อนภาพด้วยซอฟต์แวร์ Siril แต่ต่อมาก็รู้สึกถึง ความจำเป็นของอุปกรณ์ติดตาม จึงซื้อ Move Shoot Move tracker มาใช้ อย่างไรก็ตาม ความยากในการหาวัตถุเป้าหมายและการตั้งแนวแกนขั้วฟ้า รวมถึงผลลัพธ์ที่ยังไม่ดีพอ ทำให้เริ่มสนใจการสร้างแท่นกล้องดูดาวอย่างจริงจังมากขึ้น

การต่อยอดประสบการณ์ทำ PCB

ในปี 2024 ผู้เขียนบังเอิญเจอวิดีโอ YouTube เกี่ยวกับ การออกแบบ PCB แบบคัสตอม และได้เรียนรู้วิธีใช้ PCB สำหรับการผลิตจริง ที่เรียบร้อยและประหยัด แทนการต่อวงจรบนเบรดบอร์ดแบบไม่เป็นระเบียบเหมือนเดิม โปรเจ็กต์แรกคือการสร้างเทอร์โมสแตตอัจฉริยะโดยใช้ ESP32, จอ e-paper และเซ็นเซอร์ BME680 จากประสบการณ์นี้ ผู้เขียนจึงตัดสินใจนำทักษะการออกแบบและผลิต PCB ไปใช้กับแท่นกล้องดูดาวด้วยตนเอง

การศึกษาจริงจังและการใช้ทรัพยากรจากชุมชน

แนวคิดการออกแบบมุ่งเน้นไปที่ การเลือกใช้ฮาร์มอนิกไดรฟ์ โดยใช้โอเพนซอร์สจาก AliExpress และชุมชน DIY หลายแห่ง (HEMY, HrEM, DHEM, DIY EQ Mount V2 เป็นต้น) เป็นข้อมูลอ้างอิง และใช้เวลาอย่างมากในการศึกษาทั้ง การเลือกชิ้นส่วนและโครงสร้างกลไก นอกจากนี้ยังค้นคว้าข้อมูลจากโอเพนซอร์สและชุมชนเกี่ยวกับสเต็ปเปอร์/เซอร์โวมอเตอร์, การควบคุม FOC, SimpleFOC และแนวทางการพัฒนาต่าง ๆ

การตัดสินใจด้านการออกแบบและโครงสร้าง

• แกน RA (แกนศูนย์สูตร) : เซอร์โวมอเตอร์ 42AIM15 + ฮาร์มอนิกไดรฟ์ Type 17 (อัตราทด 100:1)
• แกน DEC (แกนเดคลิเนชัน) : MKS Servo042D stepper + ฮาร์มอนิกไดรฟ์ Type 14 (อัตราทด 100:1)
• แท่นและโครงครอบ: ใช้แผ่น Arca Swiss และรองรับการใช้งานร่วมกับ Move Shoot Move wedge
• โหมดการทำงาน: GEM (ศูนย์สูตร) หรือ ALTAZ (แนวราบ-แนวตั้ง)
• ไมโครคอนโทรลเลอร์: ESP32-S3
• พลังงาน: USB-C PD สูงสุด 24V/4A
• การควบคุมมอเตอร์: step/dir/en, ULN2003 + MODBUS, CANBUS
• การขยายระบบ: เปิดขา GPIO ที่เหลือออกมาใช้งานภายนอก

การออกแบบนี้ช่วยลดความซับซ้อนและเพิ่มความแม่นยำในการติดตามผ่านคุณลักษณะของไมโครสเต็ปและการควบคุมเซอร์โวของมอเตอร์แต่ละตัว อีกทั้งยังใช้ CANBUS เพื่อเปลี่ยนค่าไมโครสเต็ปแบบไดนามิก ทำให้ได้ สมดุลระหว่างการ slew ความเร็วสูง (การย้ายตำแหน่ง) และการติดตามอย่างแม่นยำ

การออกแบบ PCB และการเอาชนะปัญหา

• ออกแบบ PCB รูปครึ่งวงกลม ด้วย KiCad ให้พอดีกับเคสอย่างลงตัว
• ใช้โมดูล ESP32-S3 แบบไม่มีเสาอากาศเพื่อเพิ่มอิสระในการจัดวาง และเลือกวงจรรับไฟ USB-C (สูงสุด 24V)
• ใช้วงจรโอเพนซอร์ส PicoPD และชิป AP33772 พร้อมเลือกคอนเน็กเตอร์ตระกูล JST PH เพื่อให้ได้ การเชื่อมต่อขนาดเล็กแต่รองรับกระแสได้ดี
• ระหว่างการเปลี่ยน IC ครั้งแรก เคยเจอ ข้อผิดพลาดในการต่อ I2C และอาการทำงานผิดปกติ แต่แก้ไขได้ในเวอร์ชันที่ 2 ด้วยการตรวจสอบอย่างรอบคอบและเพิ่ม test point หลายจุด

การเชื่อมต่อกับเฟิร์มแวร์ OnStepX

นำ เฟิร์มแวร์โอเพนซอร์ส OnStepX มาใช้เพื่อรองรับการควบคุมกล้องดูดาวและการสื่อสารผ่าน WiFi ในช่วงแรกพบปัญหาด้านเสถียรภาพ โดย ESP32 ทำงานหนักเกินไปเมื่อมีการ slew ในช่วงเริ่มต้น (การเคลื่อนย้ายไปยังจุดเป้าหมายอย่างรวดเร็ว) แต่สามารถแก้ไขได้ด้วย การลดความเร็ว slew และเปลี่ยนเป็นโหมด WiFi client ผู้เขียนเพิ่มเพียงไฟล์ pin layout ที่สอดคล้องกับ OnStepX และโค้ดสำหรับควบคุมไมโครสเต็ปแบบไดนามิก ก็สามารถ ผสานรวมได้สำเร็จโดยแทบไม่ต้องแก้ไขอย่างอื่น

กระบวนการผลิตและประกอบ

ทั้งการผลิต PCB และการกัดโลหะด้วย CNC ทำผ่าน JLCPCB ทั้งหมด ผู้เขียนเลือกอย่างกล้าหาญด้วยการสั่งงาน CNC จากแบบ CAD โดยตรง โดยไม่พิมพ์ทดสอบ 3D ล่วงหน้า และได้ความแม่นยำของชิ้นส่วนที่น่าพอใจ อย่างไรก็ตาม มีข้อผิดพลาดในการออกแบบฝาครอบแกนศูนย์สูตร ซึ่งแก้ได้ง่ายด้วยการใช้สเปเซอร์ ชิ้นส่วนทั้งหมดสามารถประกอบได้ด้วยการต๊าปเกลียว M3/M4 และยึดด้วยสกรูเท่านั้น อีกทั้งยังลดต้นทุนการผลิตด้วยการ ต๊าปเกลียวด้วยมือเองโดยตรง

ประสบการณ์ใช้งานจริง

ผู้เขียนสะสมประสบการณ์ภาคสนามจากการลองผิดลองถูกมากมาย ทั้ง การตั้งแนวแกนขั้วฟ้า การตั้งค่าอุปกรณ์ และการตั้งค่าซอฟต์แวร์ (INDI, KStars, Ekos, PHD2) ช่วงใช้งานแรกมักถ่ายล้มเหลวจากปัญหาเล็กใหญ่หลายอย่าง แต่เมื่อปรับระบบจนเสถียรแล้ว ก็ทำได้ถึง ความแม่นยำระดับ 1~2 อาร์กวินาที ซึ่งเพียงพอสำหรับการเปิดรับแสง 30 วินาทีด้วยเลนส์ 600 มม. ผู้เขียนใช้ Siril สำหรับการรวมภาพ และกำลังเดินหน้าสู่เป้าหมายเพิ่มเติม เช่น การรวมภาพหลายคืน

ต้นทุนการสร้างและความคุ้มค่า

ต้นทุนรวมอยู่ที่ประมาณ 1,700 ยูโร (= รวมเครื่องมือ ฮาร์ดแวร์ และชิ้นส่วนสำหรับการทดลอง/วิจัยล่วงหน้า) หากคำนวณเป็นต้นทุนต่อเครื่อง จะอยู่ที่ราว 800 ยูโร ผู้เขียนยืนยันว่ามีความคุ้มค่าสูงเมื่อเทียบกับ แท่น GOTO เชิงพาณิชย์ (1,200~4,000 ยูโร) แต่ก็ให้ความสำคัญกับประสบการณ์การสร้างด้วยตัวเองมากยิ่งกว่า

ราคาย่อยตามรายการ (สรุปรายการหลัก)

• ฮาร์มอนิกไดรฟ์ (2 ชิ้น): 144 ยูโร
• MKS และเซอร์โวมอเตอร์ (อย่างละ 2 ชิ้น): 73~216 ยูโร
• ชิ้นส่วน CNC: 215 ยูโร
• PCB, คอนเน็กเตอร์, สกรู, เครื่องมือ และอื่น ๆ

บทสรุปและความรู้สึก

ผู้เขียนเน้นว่าประสบการณ์จากการลงมือสร้างเอง กระบวนการแก้ปัญหา และการได้ผ่านวงจรครบทั้งการออกแบบ-ผลิต-ตรวจสอบ มอบความรู้สึกสำเร็จที่ มีความหมายมากกว่าการซื้อผลิตภัณฑ์สำเร็จรูป ความล้มเหลวของ PCB Version 1 ยังสอนให้เห็นถึงความสำคัญของการตรวจสอบอย่างรอบคอบด้วย ตลอดกระบวนการ ผู้เขียนได้บทเรียนหลากหลายจากการใช้ FreeCAD, การพัฒนาทักษะ KiCad, การนำโอเพนซอร์สมาใช้ และการพัฒนาฮาร์ดแวร์โดยรวม อีกทั้งยังพิสูจน์ว่า แท่นกล้องดูดาว DIY ก็เป็นโปรเจ็กต์ที่คนทั่วไปทำได้ ด้วยความช่วยเหลือจาก เฟิร์มแวร์ OnStepX และทรัพยากรจากชุมชน

การได้สร้างแท่นสำหรับติดตามดวงดาวด้วยตัวเอง และเข้าใจมันได้อย่างถ่องแท้—คือความภูมิใจที่มีคุณค่าอย่างแท้จริง

[GN⁺]

ความเห็นจาก Hacker News

• อธิบายว่าสายเคเบิลจากแหล่งจ่ายไฟ USB-C ทำตัวเป็นตัวเหนี่ยวนำ จึงเกิดโครงสร้างแบบ LC filter ที่ทำงานคล้ายตัวกรองความถี่ต่ำ ทำให้จำเป็นต้องมีคาปาซิเตอร์บนบอร์ด เมื่อมอเตอร์ดึงกระแสสูงแบบฉับพลัน กระแสจะไหลผ่านตัวเหนี่ยวนำได้ไม่ทันตามคุณสมบัติของมัน คาปาซิเตอร์จึงจ่ายกระแสแทนไปก่อน แล้วหลังจากนั้นตัวเหนี่ยวนำจึงค่อย ๆ ส่งกระแสตามมา

• เป็นโปรเจ็กต์และคำอธิบายที่ยอดเยี่ยมมาก จังหวะก็เหมาะสุด ๆ ฉันหลงใหลดาราศาสตร์สมัครเล่นมาตั้งแต่อายุ 13 ปี มีทั้งกล้องโทรทรรศน์หลายตัว และใช้เวลามากมายดูท้องฟ้ายามค่ำคืนกับครอบครัว ไม่นานมานี้ฉันเอา SCT 10 นิ้วกับ Newtonian 4 นิ้วออกมาให้ลูกชายวัย 7 ขวบดูดวงจันทร์กับดาวเสาร์ พ่อแม่ของฉันก็ได้ดูด้วย เลยเป็นช่วงเวลาที่มีความหมายมาก SCT 10 นิ้วยังติดอยู่กับแท่นยึดแบบ fork รุ่นเก่าที่ไม่มีฟังก์ชัน GOTO ฉันก็เคยศึกษาข้อดีของ GOTO อยู่บ้าง แต่ยังไม่ตัดสินใจซื้อเพราะยังสนุกกับการหาดาวด้วยตัวเอง ตอนนี้ซื้อกล้องระบายความร้อนเฉพาะทาง ZWO 585MC มาแล้วเหมือนกัน แต่ก็เคยเสียเวลาไปมากกับการหาดาวไม่เจอ Telrad อย่างเดียวไม่พอ เลยคิดเหมือนกันว่าจะทำเมาท์จากผู้ผลิตภายนอกขึ้นมาเองด้วยความรู้ด้าน 3D printer และอิเล็กทรอนิกส์ และก็เคยคิดจะเปลี่ยนมอเตอร์เป็น NEMA 17 stepper ด้วย ระหว่างหาข้อมูลก็ไปเจอโปรเจ็กต์ PiFinder ดูเหมือนจะเป็นสมดุลที่ลงตัวระหว่างระบบอัตโนมัติกับการนำทางแบบแมนนวล https://www.pifinder.io/, และยิ่งมั่นใจว่าความก้าวหน้าของการพิมพ์ 3 มิติและการผลิต PCB จะช่วยแก้ปัญหาได้อีกมากในไม่ช้า

  • พอได้อ่านความเห็นว่าระบบ GOTO ไม่สนุก ก็ยิ่งรู้สึกอีกครั้งว่าคนเราชอบอะไรต่างกันจริง ๆ สำหรับฉันกลับตรงกันข้ามเลย ส่วนที่ไม่ชอบที่สุดคือการหาวัตถุ เลยรู้สึกขอบคุณเมาท์แบบ goto มาก
  • ถ้าเอากล้อง ZWO ไปต่อกับ Kstars/EKOS ก็ใช้ plate solving ในซอฟต์แวร์เพื่อระบุได้อย่างแม่นยำว่ากำลังมองไปที่ไหน แล้วปรับตามนั้นได้

• สำหรับโปรเจ็กต์สุดเจ๋งนี้ มีเรื่องหนึ่งเกี่ยวกับ trace บนวงจรที่อยากพูดถึง คือมีการบอกว่าทำ trace กว้างเกินไปเพื่อรองรับ 24V แต่จริง ๆ แล้วแรงดันยิ่งสูง กระแสยิ่งต่ำ จึงอาจทำให้แคบลงได้โดยไม่เป็นไร ความกว้างของ trace ควรตัดสินจากกระแส ส่วนระยะห่างระหว่าง trace ต่างหากที่เป็นเรื่องต้องระวังตามระดับแรงดัน

  • เรื่องความกว้างของ trace บนวงจร มาตรฐานสเปก IPC-2221A ช่วยได้มาก https://www-eng.lbl.gov/~shuman/NEXT/CURRENT_DESIGN/TP/MATERIALS/IPC-2221A(L).pdf
  • เห็นด้วยกับข้อสังเกตและคำอธิบายที่ดีนี้

• ยกคำจากบล็อกมา: "ตอนขยับกล้องโทรทรรศน์ไปยังเป้าหมาย จำนวน pulse ที่ส่งไปยังมอเตอร์จะมากขึ้น และเป็นภาระเกินไปสำหรับ ESP32 ตัวเล็ก" ฉันเองก็ทำงานที่ต้องควบคุม stepper motor ให้เร็วและแม่นยำ โดยยอมให้ pulse ตกหรือ glitch แม้แต่นิดเดียวไม่ได้ แกน MCU อย่างเดียวมีขีดจำกัด เลยใช้ตัวจับเวลา + DMA ในการควบคุม สุดท้ายก็ใช้ฟีเจอร์ ACT (Advanced Control Timer) ของ MCU STM32G4 ซึ่งทำให้สร้าง arbitrary waveform ได้ง่ายด้วย DMA เพียงอย่างเดียว ดังนั้นไม่ว่าแกนประมวลผลจะโอเวอร์โหลดหรืออยู่ในโหมดสลีป ตัวจับเวลาก็ไม่โดนกระทบ ช่วงนี้ก็กำลังพิจารณา PIO ของ RP2350 อยู่เหมือนกัน บน ESP32 มี MCPWM ก็จริง แต่ถ้าจะทำโปรไฟล์เร่ง-ลดความเร็วที่ซับซ้อนแบบไม่พึ่งแกนเลย 100% ก็ต้องใช้ตัวจับเวลาแบบเป็นขั้น ๆ หรือใช้อินเทอร์รัปต์ ซึ่งสุดท้ายก็กลับไปพึ่งแกนอยู่ดีและมีโอกาสเกิด glitch ได้ ACT ของ ST ทำให้มอเตอร์แต่ละตัวมีตัวจับเวลาแยกอิสระ จึงเขียนง่าย แค่ต้องอ่าน datasheet ให้ดี ส่วน driver IC เฉพาะทางอย่าง Trimanic ก็เป็นทางเลือกได้ แต่ความซับซ้อนฝั่งซอฟต์แวร์กลับสูงกว่าวิธีของฉันอีก

  • เท่าที่ฉันรู้ OnStepX ใช้แบบอิง pulse ส่วนวิธีใช้ DMA ยังไม่เคยเห็นมาก่อน แต่คิดว่าทั้งสองฝั่งน่าจะขับด้วยโหมดคำสั่งตำแหน่งผ่าน CANBUS แทน pulse ได้ OnStepX เองฉันก็เห็นเค้าลางของความเป็นไปได้นั้นในโค้ด แต่เลือก pulse mode เพราะเริ่มต้นได้ง่ายมาก
  • ตอนควบคุม stepper บน rp2040 ฉันก็เคยนึกถึง PIO แต่ติดข้อจำกัดของตัวนับ 5 บิตและขีดจำกัด 32 คำสั่ง ทำให้ใช้งานยาก สุดท้ายเลยใช้คอร์ที่สองไปคุม motion control โดยเฉพาะ แล้วปล่อยสัญญาณ step/dir แบบ bit-bang ซึ่งก็เพียงพอสำหรับโปรไฟล์ trapezoid แบบแกนเดียว
  • ถ้าอยากรู้ว่า MCU คุม stepper ได้ไกลแค่ไหน แนะนำให้ดูเฟิร์มแวร์เครื่องพิมพ์ 3D Merlin ซึ่งแม้จะเป็น AVR MCU 8 บิตตัวเล็ก ก็ยังคำนวณซับซ้อนสำหรับเครื่องพิมพ์เดลตาได้
  • เท่าที่จำได้ ESP32 ก็มี RMT อยู่เหมือนกัน ไม่ทราบว่าเคยพิจารณาวิธีนั้นไหม

• ฉันใช้ freeCAD มา 3 ปีแล้ว และพอเห็นสิ่งที่โปรเจ็กต์นี้สร้างขึ้นมาก็ทึ่งจริง ๆ ฉันชอบ freeCAD แต่ก็แทบไม่เคยเจอซอฟต์แวร์ไหนที่ทั้งดื้อและชวนหงุดหงิดได้เท่านี้มาก่อน

  • รู้สึกขอบคุณ FreeCAD มาก แต่พอโปรเจ็กต์ซับซ้อนขึ้น ฉันก็ลำบากกับอาการแครชแบบสุ่มมาก ถึงอย่างนั้นฟังก์ชันหลัก ๆ ที่ต้องใช้ ถ้ารู้วิธีแล้ว FreeCAD ก็ทำได้เกือบหมด การที่ไม่เคยใช้ CAD ตัวอื่นกลับกลายเป็นสิ่งที่ทำให้ฉันลงหลักปักฐานกับ freeCAD
  • ฉันใช้ FreeCAD ทำโมเดลเป็นงานอดิเรกมา 7 ปีแล้ว แต่พอเป็นฟังก์ชันที่ไม่เคยใช้ ประสบการณ์ใช้งานก็ยังชวนอึดอัดอยู่เสมอ ฉันเป็นนักพัฒนา FE เลยพอรู้มาตรฐาน QA และ freeCAD มี UX หลายจุดที่ไม่ผ่านมาตรฐานนั้น พอไปค้นฟอรัมเพื่อหาความต่างระหว่างข้อผิดพลาดกับคำเตือนเรื่อง overconstrain ก็เจอแต่โพสต์ที่ปกป้องนโยบายที่ตั้งใจออกแบบมาแบบนั้นในนามของ performance และบรรยากาศแบบ gatekeeping จาก power user นี่แหละคือปัญหาจริง ๆ ต้องการทั้งผู้เชี่ยวชาญ UX และ community manager ดี ๆ อย่างมาก
  • ฉันสลับใช้ OnShape กับ FreeCAD อยู่ และทึ่งกับความเนี้ยบของ OnShape มาก แต่เพราะมีโมเดลที่ซื้อมาเลยเอาขึ้น Free tier ของ OnShape ไม่ได้ ส่วน FreeCAD ก็ทำได้แหละ แต่ถ้าคิดว่า “เดี๋ยวชั่วโมงเดียวก็เสร็จ” สุดท้ายมักกลายเป็นนั่งจนดึกทั้งคืน
  • การที่มี FreeCAD อยู่ได้เองก็น่าทึ่ง และฉันก็คาดหวังว่ามันจะพัฒนาเป็นผู้ใหญ่ขึ้นเรื่อย ๆ แต่ถ้าอยากได้ผลลัพธ์เร็ว ๆ ขอแนะนำ Autodesk Fusion รุ่นฟรี ถึงจะไม่เหมาะกับคนที่ยึดหลักใช้แต่ OSS เท่านั้น แต่สำหรับงานอดิเรกแทบไม่มีข้อจำกัดและคุณภาพดี รู้สึกว่าบางทีแค่เพราะไม่ใช่ OSS ก็โดนมองแง่ลบไปหน่อย อยากให้ผู้คนเปิดกว้างกับการเลือกซอฟต์แวร์ตามความสามารถมากขึ้น
  • ChatGPT กับ Claude ช่วยงานแบบนี้ได้มาก ถ้าเป็นซอฟต์แวร์ที่มีเอกสารค่อนข้างดี AI จะอธิบาย workflow ทีละขั้นอย่างเป็นมิตรให้ได้ แม้จะมีข้อจำกัดในงานที่เฉพาะทางมากหรือมีข้อมูลอ้างอิงน้อย แต่ก็ยังเร็วกว่านั่งคลำทางเองหรือไล่ดู YouTube แบบเร่ง ๆ มาก และยังขอให้ช่วยทำ study guide สำหรับปูพื้นฐานแนวคิดได้ด้วย เพียงแต่ต้องระวังอาการหลอนหรือความผิดพลาดของ AI จึงควรขอลิงก์หรือเอกสารอ้างอิงไว้เสมอ

• ฉันสนใจมากกับโปรเจ็กต์ที่ใช้เมาท์กล้องโทรทรรศน์วัดเชิงแม่นยำด้วยตัวเอง เช่น ทำ astrometry ของดาวเคราะห์ด้วยตัวเอง ความรู้สึกเหมือนได้เดินตามรอยนักดาราศาสตร์ยุคก่อนอย่าง Kepler ที่คำนวณวงโคจรดาวเคราะห์จากการสังเกตจริง

  • เป็นหัวข้อที่น่าสนุกมาก ฉันเคยคิดต่อยอดจากงานอดิเรกถ่ายภาพสวย ๆ ไปสู่ระบบที่ทำให้ข้อมูลสังเกตการณ์สมัครเล่นเอาไปใช้วิจัยได้ ถ้ามีการแชร์ภาพดิบเฟรมเดี่ยวพร้อม metadata เช่น เวลา พิกัด calibration frame ฯลฯ ก็อาจช่วยกันทำวิจัยทางวิทยาศาสตร์หรือสร้างภาพที่สวยกว่าเดิมได้ Vera C. Rubin Observatory (หอดูดาวในสหรัฐฯ) สามารถถ่ายภาพครอบคลุมทั้งซีกโลกใต้ได้ภายในไม่กี่วัน ถ้าซอฟต์แวร์แนวนี้พัฒนาไปเป็น astronomical array แบบ crowdsourcing ทั่วโลกได้ก็คงยอดเยี่ยมมาก
  • จริง ๆ แล้ว ถ้าต้องการรู้ตำแหน่งดาวเคราะห์อย่างแม่นยำ การคำนวณจากภาพที่ถ่ายโดยจัดให้ดาวเคราะห์อยู่กลางภาพแล้วเปรียบเทียบกับพิกัดคงที่ของดาวรอบ ๆ จะให้ความแม่นยำสูงกว่าการแก้ตำแหน่งของเมาท์กล้องโทรทรรศน์เสียอีก การคาลิเบรตตัวเมาท์ให้สมบูรณ์แบบนั้นแทบเป็นไปไม่ได้ วิธีพิกัดสัมพัทธ์กับดวงดาวแม่นยำมาก
  • อีกโปรเจ็กต์ที่น่าสนุกคือการวัด light curve ของการ transit ของ exoplanet โดย exoplanet ใกล้ ๆ บางดวงสามารถสังเกตจากหลังบ้านได้แม้มีแค่เลนส์ถ่ายภาพ ตัวอย่างคือกรณีของนักสมัครเล่นคนหนึ่งที่ใช้ ASI178MM-c กับ Canon FD 300mm https://astropolis.pl/topic/60163-wasp-10-b-w-pegazie-1270-mag-00340-mag/
  • แม้จะไม่ใช่ first principles แบบเต็มตัว แต่ก็มีคนใช้ Seestar S50 roboscope ร่วมกับ diffraction grating เพื่อวัด emission spectrum ของดาวฤกษ์
  • เสริมอีกนิดว่า Kepler ทำงานวิจัยจากข้อมูลสังเกตการณ์ด้วยตาเปล่าของ Tycho โดยไม่มีกล้องโทรทรรศน์

• เป็นโปรเจ็กต์ที่ยอดเยี่ยมมาก ดูเหมือนว่าตอนออกแบบ PCB อาจไม่ได้ใส่คาปาซิเตอร์ ตัวต้านทาน ฯลฯ ที่เหมาะสมครบถ้วน ทำให้ไมโครคอนโทรลเลอร์เสถียรไม่พอ เลยสงสัยว่าปกติทุกคนตัดสินใจกันอย่างไรว่าต้องมีชิ้นส่วนอะไรบ้าง เช่น decoupling capacitor ควรอ่าน datasheet แล้วใส่ตามทั้งหมดเลยหรือไม่

  • ต้องดู datasheet เป็นเรื่องจำเป็น เพราะส่วนใหญ่จะมีตัวอย่างวงจรบังคับหรือวงจรขั้นต่ำมาให้และควรอ้างอิงเสมอ นอกนั้นแนวปฏิบัติที่ดีคือใส่ decoupling capacitor ใกล้ขาชิป ทำกราวด์ให้เสถียร และทำตาม reference layout การดูวิธีคิดของวิศวกรที่มีประสบการณ์ก็ช่วยได้มากเช่นกัน (ตัวอย่าง: https://www.youtube.com/watch?v=aVUqaB0IMh4)
  • datasheet ของชิ้นส่วนแทบทั้งหมดจะมีวงจรขั้นต่ำและ reference design อยู่ ส่วนเรื่อง ground plane ความยาวลายสัญญาณ ฯลฯ มักอธิบายใน application note แยกต่างหาก
  • เวลาออกแบบวงจรไมโครคอนโทรลเลอร์ การอ้างอิง development board ที่เปิดเผยวงจรก็เป็นจุดเริ่มต้นที่ดีมาก
  • นอกจากดู datasheet แล้ว ถ้าใส่ decoupling capacitor ให้ใกล้ที่สุดเท่าที่ทำได้กับขาไฟทุกขา และกันพื้นที่ PCB ด้านหนึ่งเป็น ground plane ก็มักแก้ปัญหาได้เกือบทั้งหมด

• สิ่งที่ประทับใจเป็นพิเศษคือการสั่งทำชิ้นส่วนโลหะ CNC ฉันเองก็เป็นมือใหม่ด้านการออกแบบ CAD และอยากเรียนรู้บ้าง

  • ลองสมัครเข้า makerspace ใกล้บ้านแล้วใช้ machine shop ดู พวกเขามีทั้งการอบรมและการรับรองการใช้เครื่อง CNC ฉันเคยลองออกแบบแผ่นโลหะเรียบง่ายสำหรับอุปกรณ์ถ่ายทำภาพยนตร์ด้วย CAD มีตัวสร้าง G-code แบบง่าย ๆ และมี simulator สำหรับเช็กการชนด้วย แต่ทุกครั้งที่ไปจะเริ่มผลิตจริง เครื่องมักใช้งานไม่ได้เพราะมีใครทำหัวเครื่องพังไว้ สุดท้ายเลยต้องทำด้วยมือเอง ทำให้บางมิติไม่ตรงเป๊ะ พอมารู้ทีหลังว่ามีบริการ CNC รับจ้าง ก็เสียดายที่ไม่ส่งงานไปทำโดยตรง
  • ที่จริงมันง่ายมาก แค่อัปโหลดไฟล์ step ก็เช็กราคาและความเป็นไปได้ในการผลิตได้ทันที https://jlccnc.com/cnc-machining-quote

• เป็นโปรเจ็กต์ที่เจ๋งมาก ฉันสงสัยว่าค่า PCB ที่แพงนั้นเกิดจากงานประกอบหรือเปล่า เพราะถ้าอ้างอิง JLCPCB บอร์ด 2 ชั้น ขนาดไม่เกิน 100mm ผิว HASL และตัวเลือกพื้นฐานอื่น ๆ ปกติราคาถูกอยู่แล้ว เลยอยากรู้ว่าร่องสำหรับแผ่นยึดคอนเน็กเตอร์ USB มีค่าใช้จ่ายเพิ่มไหม สั่งประกอบทีละกี่แผ่น สัดส่วนการเลือกชิ้นส่วนจาก standard/extended library เป็นอย่างไร ถ้าบัดกรีเฉพาะคอนเน็กเตอร์เองราคาจะต่างแค่ไหน และจริงไหมที่ถ้ามีชิ้นส่วนจาก extended library แม้แต่ตัวเดียว ค่าหยิบวางประกอบของทุกชิ้นก็จะเพิ่มแบบแยกรายการ ทำให้การลดจำนวนชนิดชิ้นส่วนคือกุญแจหลักในการลดต้นทุน

  • ใช่แล้ว ต้นทุนหลักมาจากงานประกอบจริง ๆ ตัวบอร์ดใช้ JLCPCB 2 ชั้นพร้อมตัวเลือกพื้นฐาน และเพิ่มแค่สีดำเลยแพงขึ้นนิดหน่อย สั่งทีละห้าชิ้นเพราะเป็นจำนวนขั้นต่ำ พยายามเลือกชิ้นส่วนจาก standard library ให้มากที่สุด แต่พอเกินพวก passive component ไปแล้วก็มีข้อจำกัด ส่วน through-hole ถ้าบัดกรีเองจะต่างแค่ไหนฉันไม่แน่ใจ แต่ก็คงไม่มากพอให้ใส่ใจ การลดจำนวนชนิดชิ้นส่วนช่วยได้จริง เช่น ถ้าต้องใช้ตัวต้านทาน 4k กับ 6k ก็อาจคุ้มกว่าถ้าใช้ 2k ห้าตัวมาประกอบแทน

• โปรเจ็กต์นี้น่าประทับใจมาก ฉันเองก็เคยอยากซื้อเมาท์ harmonic drive ขนาดใหญ่ให้กล้องของฉัน แต่ติดที่ราคาสูงเกินเอื้อม ระหว่างใช้เครื่องมือ EKOS/Kstars/INDI ก็เจอการลองผิดลองถูกเยอะเหมือนกัน ถ้าต้องการควบคุมอุปกรณ์ indi จาก Python ฉันมีโค้ดที่เขียนไว้ https://github.com/dahlend/contindi

  • อยากรู้ว่าแรงบันดาลใจของโค้ดนี้คืออะไร เพราะดูเหมือน EKOS เองก็มีฟังก์ชัน scheduling ที่ดีอยู่แล้ว ฉันเองก็เคยเขียน terminal interface (TUI) ตอนรัน INDI server บนมินิคอมพิวเตอร์ MeLE 4C ด้วย https://www.svendewaerhert.com/content/blog/telescope-mount/inditui.png, และเพราะปัญหาเรื่องความเสถียรของ GNOME remote desktop เลยเปลี่ยนไปใช้ INDI server แบบ headless/remote ตอนนี้กะว่าจะเก็บกวาดโค้ด TUI ให้เรียบร้อยแล้วค่อยเอาขึ้น Github เร็ว ๆ นี้