Close
0%
0%

TrillSat

Texting Without Cell Towers, Power Grid, or the Internet: IoT meets AX.25 Aboard an Arboreal Space Elevator

Similar projects worth following
TrillSat is an experimental, solar-powered, robotic radio relay with a 2m/AX.25 to WiFi/XMPP gateway and multi-user PBBS with in-session APRS beaconing over a single VFO. It has a weatherproof, temperature-controlled, low-cost design and uses a capstan hoist to climb a single, nylon tether to achieve high elevation for line-of-sight VHF, using the same drive motor for pendular tilt of a solar tracker. This kinematic constraint and catenary of the tether restricts the angle to an arcing, spiral axis for near dual-axis efficiency which is aligned using an accelerometer, Hall-effect, and LDR sensors. To counter the axial sway, the craft includes a passive ball damper, slow PWM startup routines, experimental sway-cancellation, gyroscopic reaction wheel and inertial stabilizer. An inductive Qi coil allows smartphone charging and a dock for a future LoRa "space pod". It includes mechanical energy re-capturing for motor assist and an experimental haptic Morse Code system.

Introduction

Not everyone can afford to send spacecraft aboard rockets into space, and the space elevator is still science fiction due to materials that have yet to be invented. CubeSats are making progress, but they are tiny and still cost prohibitive for an individual.  Their small surface area limits the amount of solar energy that they can gather unless sophisticated unfolding techniques are used.

High altitude, specifically Height Above Average Terrain (HAAT), is necessary for certain line-of-sight radio transmissions, and if we can get a craft high enough, it can be both an analog of a spacecraft and a teaching tool.  Amateur radio operators know, for instance, that even a relatively small and inexpensive 5-watt, 2-meter HT (handie-talkie) can reach the International Space Station. In fact, they have such a radio onboard to communicate back down to us.  One of my favorite authors, Arthur C. Clarke, was also an oft-forgotten radio specialist/physicist and helped to invent the communication satellite and inspire the space-elevator.  He had a talent for predicting the future and wrote about interesting spaceships with onboard intelligence and docking space pods, all of which have intrigued me for years.  While high-altitude platform stations, geostationary or moored balloons are intriguing, these types of aerial objects are heavily regulated in my country, especially where I live.  Like lighthouses that warn ship captains of rocky coasts, it is understandable that our aircraft pilots need to know where aerial hazards are at all times.

I grew up and still reside near the main airport in St. Louis, the old Lambert Field where Charles Lindbergh was one stationed, and he once lived just down the street from where I am today.  My grandfather loved airplanes and frequently recounted the regret he felt when he had to burn a captured Japanese Zero in WWII, and I went to the airport with him often to watch the passenger planes land and meet my father, as he traveled a lot. While it was convenient for traveling, the thought probably never occurred to them that proximity to an airport placed severe restrictions on what we could actually fly in the air.  This was an unfortunate irony as a kid, since I loved aeronautics;  my neighborhood was of large percentage McDonnell Douglas aerospace engineers (now Boeing, near the site of where the Mercury space capsules were constructed). One of my classmates even became a NASA astronaut, and I watched in awe as he installed the Dextre robotic arm aboard the ISS (and was chosen to fly aboard a SpaceX Falcon 9 in 2019).  My parents and grandparents, however, were not engineers and had little math and science background.  Three of them were elementary school teachers, masters of the English language and the arts, inspiring limitless possibilities within me if I put my mind to it.  My father was not a teacher, and English was not his strength.  But he was an explorer himself, an artist/designer at heart, and through his creations, I saw him bring to life some of those possibilities.  One day, out the blue, he built a kite out of gift-wrapping paper, a style that I had never seen before, and it flew beautifully.

But, while they couldn't help me with my algebra, they provided me with the encouragement, freedom, and tools at an early age so that I could teach myself through language and communication, so that I could gain the knowledge to claw my way up that alien mountainside to see what those mathematicians and scientists saw as they...

Read more »

TrillSat-1.1.tgz

An updated version of the TrillSat source code, to include the new THUMP haptic system, licensed under GPL 3.0, including the OpenSCAD 3D part generator, along with the C, Lua, Python, and BASH sources for the 4 interoperating CPUs and the electrical schematic.

gzip - 2.08 MB - 08/25/2018 at 03:15

Download

TrillSat-1.0.tgz

A copy of the first released tarball of the TrillSat source code, licensed under GPL 3.0, including the OpenSCAD 3D part generator, along with the C, Lua, Python, and BASH sources for the 4 interoperating CPUs and the electrical schematic.

gzip - 2.08 MB - 06/02/2018 at 03:36

Download

trillsat.webm

Animation of TRILLSAT-1 in WebM VP9 format, showing the rocking, orbiting motion (rough estimates only, exaggerated for clarity). This file is about 88% smaller than the original animated GIF.

video/webm - 1.11 MB - 06/07/2018 at 06:12

Download

trillsat_schematic.png

Full electrical schematic, version 1.

Portable Network Graphics (PNG) - 2.03 MB - 04/07/2018 at 06:47

Preview
Download

trillsat_power_regulation_circuit.png

A simplified diagram of the power regulation circuit controlled by ATtiny 1634 (Huckleberry)

Portable Network Graphics (PNG) - 271.62 kB - 04/07/2018 at 07:35

Preview
Download

View all 61 files

  • 1 × 14-Watt X-Dragon Solar Charger (Extracted SunPower solar cells and USB charge controller)
  • 2 × iKits 10,200 mAh USB Powerbanks (Extracted NCR18650B cells and USB charge controller)
  • 2 × Inland 1.7mm PETG Filament White 1kg
  • 1 × Clear Acrylic Sheet 18" × 24" x .100", High-gloss, UV-resistant
  • 1 × Baofeng UV-5RA 2m/70cm radio and headset (Extracted amateur radio transciever and headset magnet)

View all 40 components

  • Requiem for a Space Elevator

    Lee Djavaherian09/07/2018 at 10:52 0 comments

    The Japan Aerospace Exploration Agency (JAXA) is said to launch a tiny space elevator next week.

    Just like TRILLSAT-1, it isn't a "real" space elevator, as this is still the domain of science fiction, but it serves as a miniature test platform.  But the Japanese spacecraft is said to be the first experiment of a tethered "elevator movement" in actual space, which is pretty cool.

    My TrillSat project will no longer be updated on this Hackaday.io project page, and any future updates will resume on its main site at http://greatfractal.com/TrillSat.html.  I plan to take a long break before I resume, as this competition sucked most of the fun out of it for me.

    TrillSat's latest subsystem #Tethered Haptics Using Morse Pulses was a project page I specifically created for the Human-Computer Interface Challenge (since the judges ignored TrillSat completely in the first 3 challenges), so this actually marks the 4th loss for TrillSat in a row.

    As evident from my log entry back in July, the 2018 Hackaday Prize competition has been one of the most disappointing experiences in my life, something I will never repeat, as I rarely extend myself or personal projects in this way.  I was overjoyed back in March 2018 when the competition was first announced to find out that TrillSat qualified for 4 of the 5 challenges and felt like the luckiest person in the competition.  It is inconceivable to me that all 80 of the winning projects so far could have beaten TrillSat on merit--and this prevented it from even entering the finals.

    The only reason that I decided to put in the final effort for the 4th challenge was mainly a matter of principle--it served to complete what I originally set out to do back in March.  Suffice it to say, while TrillSat is an open-hardware, power-harvesting, robotic platform with numerous human-computer interfaces and thus directly qualified for 4 of the 5 challenges, it is definitely not a musical instrument and won't be entered into the 5th challenge.  The judges can relax and don't have to look at it any longer.

    Again, thanks followers/likers for recognizing this project--it was the only beacon of light in a dark place.

    TRILLSAT-1, signing off.

  • Centripetal Force and the BLDC Gyrofan

    Lee Djavaherian08/28/2018 at 01:00 0 comments

    I started to look more closely at the centripetal force equation, since I've been wary of raising the Gyrofan speed higher with its full mass, as I didn't know exactly how much force was being generated.  I'd like to ramp the thing up to get appreciable inertial stabilization, since my first test of the Gyrofan on the tether a few days ago had little effect at 360 RPM.  The equation, though, shows that I was way too conservative and underestimated the non-linear effect of RPM on centripetal acceleration. 

    I also forgot that the high pitch of the sound isn't generated by the frequency of rotation but by the frequency of the electrical steps/pulse generation, which is much higher on a BLDC.

    As the gyro speed increases (which increases gyroscopic stabilization), centripetal acceleration increases exponentially.  And since centripetal force (and the related centrifugal force) is mass x acceleration, the force increases exponentially, too.  If you double the RPM, for example, the force doesn't double, it squares.  Doh!

    The 24 steel spheres and their PETG sockets are somewhere around 5 grams each, plus or minus a few grams (heck, I forgot to even weigh them before I closed up the case!).  At 360 RPM with a radius of around 5 cm, this creates a force of only around .08 lbf (.36 N).

    But at 3 times that RPM (1080 RPM), the force would go up to around .72 lbf (3.2 N), 9 times the force, since 3 squared is 9.

    And at 50 times that RPM (18,000 RPM), the force would go up to around 200 lbf (888 N), 2500 times the force, since 50 squared is 2500.

    So this presents an interesting situation, since the actual stabilization effect is related to angular momentum, and is not exponential.  In other words, I have to spin it fast to get the stabilization to occur, yet the unwanted force on my wheel starts to go up exponentially...

    I am still down in the low numbers, though, and so I tried sending a gyro 33 command to ramp it up to 1320 RPM, which applied approximately 1 lbf of force (4.8 N) around the wheel.  It runs for a few seconds, but then cuts off before I can evaluate it.  For some reason, my stall detection code is randomly activating and is shutting down the BLDC.  What is weird is that this bug occurs less often when the craft is tilted to the starboard side, and more often when tilted to the port side, but I've ruled out the accelerometer.  And I don't think this is related to gyroscopic precession, either, since it also occurs at really low RPMs.  Very odd.  So I have to review all of my gyro code (and maybe even open up the case to check for loose connections) before I can resume testing.

    My BLDC code is a nightmare, by the way, mainly due to the fact that I couldn't use the 8-bit hardware timer to drive the pins directly.  I'm using them for other things, and even so, I need 3 pins for the 3-phase motor, but there are only 2.  I use the pin change interrupts to detect the 3 hall-effect sensors, but for PWM, I used the 8-bit overflow and CTC interrupts to chop the power to the coils, using software routines to changes the pin states.  And all kinds of bad things can happen:  the pin states can change while I'm trying to read their states, counter overflows can occur, the timer interrupts can occur outside of my functions before I get a chance to read them, my code might not complete before the next interrupt, etc.  There are still a lot of bugs that I need to work out.

    The new ATtiny 1616 that came out last year would solve some of my problems, but I just need to improve my ATtiny 1634 code and find creative ways to handle it.  I've got the main drive motor and haptic morse detection running on the 16-bit timer, and I use the 8-bit timer for the gyro and miscellaneous functions.

    When the BLDC runs at higher RPMs, every clock cycle counts, but unfortunately I do a lot of things inside my interrupts which eat up a lot of the available cycles.  For...

    Read more »

  • Updated TrillSat and SimtheoDecoder to Version 1.1

    Lee Djavaherian08/25/2018 at 03:28 0 comments

    Ok, I made the first update to the TrillSat source code since it was published almost 3 months ago, primarily to add the new #Tethered Haptics Using Morse Pulses subsystem, and added it to the Files section.  The trillsat.c source is now dependent on (and performs a C include of) simtheo.h, my external Morse decoder module, and is now also dependent on eeprom.h (from the avr-libc project) for the haptic passcode storage.  The trillsat.c source also adds the appropriate defines, global variables, pin/interrupt/timer initialization; adds two ISR interrupt routines for Sawyer and Huckleberry, adds a new function called Process_Haptic_Command to perform the actual command processing, adds the EEPROM haptic lock routine, and it, along with trillsat_bot.py, adds the new XMPP and THUMP commands. 

    They also temporarily disable the haptic system and reset the correct 16-bit timer prescaler during motor operations, but they do not yet tell Huckleberry to turn on the LED (in case it was grounding the MISO line which prevents hall-effect feedback during a non-haptic motor operation).  For now, I just control this manually using a new hucklight [1|0] command during testing.  And the BASH programming scripts for the two ATtinys for in-circuit programming were updated to compensate for the new haptic system running over the same line.

    The simtheo.h C module is statically linked, compiled at the same time as trillsat.c.  In the future, I plan to clean up the module to allow it to be dynamically linked, but for now, I just wanted to make sure that all of the code was published to show how the THUMP system was implemented for a capstan cablebot.  I also updated simtheo.h to remove a small delay that was causing problems and to correct a typo in the README file.

    The THUMP system can, of course, be implemented differently in different situations, depending on the type of craft or function it performs, but this is how I implemented it for TRILLSAT-1.

  • Four New TrillSat Videos

    Lee Djavaherian08/24/2018 at 01:31 0 comments

      I spent the last three days making 4 new videos for TrillSat:

      1. Introduction
      2. XMPP Command System
      3. Tethered Haptic Morse Code System
      4. Inertial Gyrofan

      I still need to make 3 more videos (the power regulation, motor drive, and packet radio systems), but these are more complicated for me to demonstrate, so I'll work on those videos at a later time.  But I hope they now give you a better feel for the device, such as the scale of the craft, how it swings, and how the command systems work.  It's buggy and rough, but it's a real thing.

      I decided to go ahead and create a YouTube channel called TrillSat just for this project and moved my old motor control test video to the new channel.  Anyway, here they are:

  • ​Complex Orchestration of Systems

    Lee Djavaherian08/21/2018 at 05:33 0 comments

    Over at my new #Tethered Haptics Using Morse Pulses project, I have decided to leave the haptic system enabled full time on the TRILLSAT-1 prototype, instead of just during low-power situations, and have created a new EEPROM haptic passcode validation system which reduces the chances of nature (or a casual passerby) to spontaneously enter commands over the tether.  A two-capital-letter passcode is set via XMPP which allows 676 combinations.

    While simple to use in a "typical" system, implementing all of this on TRILLSAT-1 is more complex due to both its oblique angle (and another angle which changes depending on the sun), and the fact that it resource-shares a single overloaded MISO line using two ATtinys running in parallel.  I'm essentially cramming a new, full-time system onto an already overloaded line, and all of these systems have to be carefully orchestrated.  There are some interesting nuances in exactly how the circuits and software need to interact to allow successful operation.

    The MISO Line

    The SPI Master In Slave Out line is now used for five different purposes:

    •     Occasional bitbang SPI in-circuit programming of the two ATtiny microcontrollers
    •     On/Off control, by both the Pi and ESP8266, of the LED spotlight
    •     Motor position alignment via a hall-effect switch read by Sawyer (the motor-control ATtiny)
    •     Serial bus between Sawyer and Huckleberry (the power-regulation ATtiny) for repeating standard Morse code characters from haptic input
    •     On/Off control of the LED spotlight by Huckleberry

    And the settings vary depending on whether or not the Pi and ESP are up or down, the LEDs are on or off, the position of the motor is aligned over one particular hall-effect switch, and whether any in-circuit programming or haptic communication is taking place.

    The I2C Lines

    Two I2C lines (which are also used as SPI lines) are shared by two masters (Pi Zero W and ESP8266) and three slaves (LIS3DH and two ATtiny 1634 microcontrollers), but the infamous hardware I2C clock-stretching bug on the Pi has caused many difficulties over the last two years, forcing me to both slow down the bus and spawn off jobs in parallel so to not delay the line.

    These lines are the only way to access the LIS3DH registers, so if the Pi or ESP go down, the LIS3DH can only generate interrupts to one of the ATtinys based on previous settings and the registers can no longer be set dynamically.  So I had to make sure the Pi (or ESP) sets it correctly before any power failure occurs.  Because the three slave devices cannot communicate with each other, the only options for the ATtinys would be to set variables which are polled by the Pi or ESP, if active, so they can then send master I2C commands as needed.

    The LED Spotlight

    The LED serves as both a spotlight for illumination and also an important diagnostic tool, allowing Morse code output to be visualized without turning on the haptic motor, and it can even flicker when performing SPI programming without affecting the data integrity.

    If all systems are operational, the ESP should keep the LED spotlight ON (floating), but the Pi should keep the LED spotlight OFF.  Because the LED is being controlled at the transistor base after the series resistor, it doesn't ground the entire MISO line and leaves it usable.  So the Pi and ESP can keep the LED off, yet still allow the MISO line to operate for SPI programming, haptic Morse signals, and hall-effect motor position detection.  But if Huckleberry needs to control that LED for testing when pulsemode is 0 (visual only; no haptic), the Pi and ESP must relinquish their hold on the LED spotlight, and then Huckleberry can control it.  Sawyer can control it too, but it never needs to.  It just needs to monitor that line at all times for its hall-effect switch, in-circuit programming, and incoming haptic signals....

    Read more »

  • Haptic Morse Code System is Working

    Lee Djavaherian08/16/2018 at 09:04 0 comments

    The Tethered Haptics Using Morse Pulses (THUMP) subsystem is now working on the TRILLSAT-1 prototype which allows two-way haptic communication using the A-Z subset of International Morse Code.  It operates in parallel on both ATtiny CPUs, and creates its own serial bus protocol for daisy-chained, asynchronous operation.  I've published a separate project page for it called #Tethered Haptics Using Morse Pulses and entered that project into the 2018 Human Computer Interface Challenge.  I also released my SIMTHEO Decoder module source code under LGPL 3.0.  It can be useful for a variety of different types of tethered robots, such as hoistbots and winchbots (and oblique, capstan cablebots, like TrillSat).  I will release the updates to the TrillSat source code when I get a chance, which will show exactly how the THUMP subsystem is applied to the TRILLSAT-1 prototype.

  • Hope, Revisited

    Lee Djavaherian08/10/2018 at 02:14 0 comments

    Six days ago, one of my 1980's school classmates was announced by NASA to be one of the first two US astronauts to fly on a commercial SpaceX Falcon 9 rocket, scheduled for next April, finally returning the US to human spaceflight after the shuttle program ended.

    In the NASA photo, he is 3rd from the left, giving a big smile and thumbs up like All Might (for any My Hero Academia fans out there...)

    I had mentioned him months ago in the Introduction section of this project, since his achievements over the years were one of my motivations for actually building TrillSat as a self-contained satellite/spacecraft analog and not just a traditional radio station (and like many astronauts, he even has a ham radio callsign--how cool).

    Thanks, Bob, for setting the bar extremely high (literally) and reminding me that it is still worthwhile to do things "not because they are easy, but because they are hard".

    The TrillSat project on Hackaday has been reactivated and work has resumed.  More details to follow.

  • Build hope?

    Lee Djavaherian07/25/2018 at 02:43 3 comments

    The twenty 2018 Hackaday Prize Power Harvesting Challenge winners were announced today, and again I did not win a single thing, not even a non-monetary achievement.  This is the 3rd loss for TrillSat in a row, and I see a trend here, unfortunately.

    You'd think that its unique mass-tilt/catenary spiral-axis solar tracker (both elevating the craft for line-of-sight radio communication and approaching dual-axis efficiency) using a single $9 screwdriver motor (with a custom H-Bridge built into the handle) would win at least something, right?  If so, you would be wrong.

    You'd think that the only tether/winchbot in this year's Hackaday Prize competition might have a chance to win something.  Heck, at the time of this writing, tether or winchbots are relatively rare, and TrillSat uses an onboard capstan winch for aerial locomotion, which is very rare (I've never even seen one used in this way before) and uses complex PWM drive mechanics.  And it even has a gyrofan, using mass x velocity for experimental inertial stabilization built out of a repurposed DVD spindle motor, and the BLDC is driven via programming of a single ATtiny.  But alas, it didn't win the robotics round--not even a non-monetary achievement.  The capstan was kicked to the curb.

    You'd think that a tiny audio/data/PTT interface custom-built to connect to a $26 ham radio (which was dismantled to eliminate weight and allow variable power from both series cells and boost converters) with a custom program that uses 16-byte chunks to quickly program the clone-mode flash to allow it to mimic the features of more expensive dual VFO's for both APRS/Packet functions during a single session would at least win something, even a non-monetary achievement, right?  Sorry to disappoint you again.

    You'd think that a custom Packet BBS in Python on a Pi Zero using Unix standard streams instead of the C library, connected to a custom XMPP server in Lua/NodeMCU on an ESP8266, things that had never been programmed on those architectures before (to the best of my knowledge) would at least earn the smallest of awards--again, nope.  I even had to build a software simulation in order to test it, since I couldn't put it on the air.  Heck, I even added waterproof, inductive Qi charging...  Cool, right?  The judges don't seem to think so.

    And you'd think that showing proficiency with 4 interconnecting CPUs and 4 languages ATtinys (in C), ESP8266 (in Lua), Pi Zero (in Python/BASH) on a single project might garner some cred from the judges, right?  Nah!  It doesn't appear they look at such trivial things...

    Oh, and the care taken to design all parts in OpenSCAD so the majority of the unit could be printed on a Prusa i3 printbed in PETG (built from kit, no less), using pronsole on a Raspberry Pi 3 would garner at least a tiny bit of modern maker cred, right?  That would be a big NO.

    Oh yeah, and the wooden Ark and Test Frame support structure that I had to build to test and calibrate the unit indoors--it's another project in itself: it folds, uses counterbalanced tethers, collapses for storage, and assembles and operates in several different modes.  Neat, right?  Ha!  No prize for you!

    And finally, I built an actual weatherproof, temperature-controlled prototype (it's not just vaporware like some of the projects), strong enough for testing, and I published all of the source code, schematic, and video.  I also documented it in great detail (almost 200 pages), including an itemized Bill of Materials.  But I also went through the trouble of writing up separate project text for Hackaday (until I ran out of room).  Did I get recognized for such meticulous work?  Of course not.

    I don't see this trend changing and have therefore decided not to enter my haptic, tethered Morse code system into the 4th challenge (Human-Computer Interface).  The competition is over for me.  All future updates...

    Read more »

  • First Video of Motor Testing

    Lee Djavaherian07/16/2018 at 06:14 0 comments


    I just published the first video of the two motors in operation, showing the tilting of the solar panel/capstan hoist mechanism on the tether using the wooden Ark and Test Frame and also showing the Gyrofan used for inertial stabilization.  It's the first YouTube video that I've ever uploaded, and it's pretty crude.  I was able to fully load the mass on the gyro wheel and ramped it up to a fixed RPM, which it holds fairly constant, based on hall-effect sensor feedback.  The wagon-wheel effect is pretty mesmerizing.

    I also made a pass at computing the solar position using just the two CdS LDRs at rest, instead of relying on sunrise/sunset tables, but the trigonometry is surprisingly tricky.  It's easy to find the brightest part in the sky--you just move the craft until the two opposing LDR sensors are close in value to one another, but it's much more difficult to estimate solar position using just these values alone.  In other words, to have the craft "see" the sun and report its exact position is difficult. 

    First you have to know the angle of the craft (which I already know via the accelerometer), and then you have account for Lambert's cosine law, which is fairly easy.  But if the angle of the craft is not horizontal (or even stationary), you don't really know which side of the sun to which one of your LDRs might be pointing.  I can use sunrise/sunset tables for my location, but this requires an accurate clock, which is also a problem (as the lack of RTCs means that I have to manually set my clocks, and auto-setting them from solar position isn't accurate to more than around 30 minutes, which brings me back to the same problem...).  So rather than estimating "where" the sun is, for now I'm going to have to just go out and find it like traditional solar trackers do, by moving the motors to find the brightest point.

    I'm encountering some additional problems, too:  the paracord sheath tends to slip over time, allowing the internal fibers to bunch-up, making the mechanism less smooth as I test.  Testing it on the rough PETG snags and takes a toll on the fibers.  And the Sign-Magnitude/Lock-Antiphase orbital mechanics that work so well testing on a table, which I added to my Park command, need to be heavily tweaked for the forces on the tether.

    The capstan/motor is powerful enough to drive and tilt the craft, but the PWM slow-starting torque is low, and raising the torque to overcome the static friction causes jerks.  These jerks were fairly low in early testing on the tether, but when I attached the heavy Planetary Mass, the jerking is heavily exaggerated.  So I'll have to pulse the motor at higher current to overcome the static friction, then quickly slow it down.  I might also experiment with PFM modulation in the future.

    If you notice, in the video, you can hear the high-pitched whine of the PWM (since I use audible frequencies), but I have to raise the duty cycle fairly high before it starts moving (unless it is on a "downhill", and then it whips around really fast and has to be slowed down (which adds wear to the paracord).  The ball-damper that I added inside Planetary Mass helps to remove the stress of the jerks, though.

    The orbital mechanics aren't going to be a graceful truck driving down a smooth, sinusoidal hill, as I illustrated in my diagram--that's just the idealized path.  In reality, it's going to be like a old truck driving down a bumpy, rock-strewn road full of potholes.  The driver will have to hit the gas hard at points, then let off and hit the brakes, etc.

  • Released Source Code Today

    Lee Djavaherian06/02/2018 at 05:21 0 comments

    Ok, the first version of the source code for TrillSat was released a couple of hours ago under GPL 3.0, and a copy of the source tarball was uploaded to the Files section of this project.  It includes the most important files, the OpenSCAD program that generates the STL files for 3D-printing (and animation), the electrical schematic, the C source files for the two ATtiny 1634 microcontrollers, the Lua source for the Huzzah ESP8266 running NodeMCU, and the Python 2/3 and BASH sources for the Raspberry Pi Zero W.  The README file also details several smaller changes that need to be made to various configuration files.

    The tarball doesn't contain the entire project, only the core craft design files, so I didn't include the 100+ pages of technical information which are available on my TrillSat home page at http://greatfractal.com/TrillSat.html, since I wanted to keep the tarball small.  I also left out the STL and G-code files that I used to print the parts, since they consumed several megabytes (and are easy to generate using my OpenSCAD program and Slic3r), and I left out the KiCad source and library files as I only use it for the visual schematic and don't use any of its other features.

    The "Three-Tridant Orbital Mechanic" PWM drive system is now working, but it is very crude at this stage.  I created a new "Park" command which drives the Planetary Mass at different acceleration/deceleration values and speeds as it passes the Hall-effect switches, automatically switching between Sign-Magnitude and Lock-Antiphase on-the-fly to re-park the mass at sunrise position during the night (and lifting the entire weight of the craft).  It works in testing on a table, but I have not yet tested this system on the tether (and I will probably need to tweak the values to match different friction/torque requirements).

    I had to match the speeds of Sign-Magnitude and Lock-Antiphase to ensure smooth hand-offs, since Lock-Antiphase runs at twice the frequency of Sign-Magnitude, so I sped up Sign-Magnitude to compensate, rather than slow Lock-Antiphase down.  Lock-Antiphase has half the resolution, so slowing it down won't allow a perfect match with Sign-Magnitude during a non-linear acceleration, but Sign-Magnitude can have its resolution cut in half to match, which preserves the congruence.

    I also had some spontaneous ATtiny reboots during testing, since I moved my bypass capacitor too far away from the ATtiny after I replaced the last BLDC, and the supply voltage dropped below my brown-out detection threshold of 4.3 volts, so I lowered it to 2.7 volts which helped until I can get around to fixing the problem.

    The code is crude at this stage, but hopefully it will give others insight into solutions for several problems that I had to overcome:  how to take control over the UV-5RA flash memory and minimize writes to the flash using 16-byte blocks (something Chirp wasn't designed to do), how to create a crude XMPP server on a memory-constrained ESP8266 running NodeMCU, how to program a PBBS using AX.25 Unix programming techniques instead of the C library, how to craft the APRS message, and how to wrangle a custom radio interface using a Virtual UART and Virtual PTT line.

    It also shows the various ways to control the two very different types of motors under PWM (brushed and brushless) using a single microcontroller, maxing out both of its hardware timers and creatively using interrupts.  And of course, there are a lot of different types of IPC, job processing, multiprocessing and concurrency going on with 4 CPUs that interoperate.

    It is a fascinating experience for me, and I hope you find some of it useful.

View all 16 project logs

Enjoy this project?

Share

Discussions

emadsakhaee wrote 09/23/2018 at 16:28 point

& write a paper about  some thingd

  Are you sure? yes | no

emadsakhaee wrote 09/23/2018 at 16:27 point

hi.. I like work to you.

  Are you sure? yes | no

Bruce Land wrote 08/16/2018 at 11:42 point

Reminds me of the SciFi story in IEEE Spectrum magazine.
https://spectrum.ieee.org/computing/networks/synthetic-serendipity

  Are you sure? yes | no

Lee Djavaherian wrote 08/17/2018 at 09:04 point

That's an interesting link, Bruce!  Or should I say, Chumlig/Big Lizard? :) I just read the story and am surprised that Vinge predicted such patterns back in 2004.  It makes a lot of prophetic societal commentary.  I especially like the commentary on tech ageism, which is worse today than it was back then.

The tree-based ad-hoc mesh nodes in the story, which need line-of-sight for their lasers, do remind me in some ways of TrillSat (a tree-based, line-of-sight, AX.25 node).  And the "silent messaging" finger-tapping mode used by older people in the story is also similar to TrillSat's tethered haptic decoder.

But there are important differences: one reason I didn't install a camera on TrillSat (but only left an empty void for it as an "optional camera") wasn't just because it was too expensive, but that I wanted it to be a communication relay and not a surveillance device.  Also note that I don't use the IoT device to connect to the Internet--I only use its TCP/IP stack to communicate with the craft itself, a big distinction.

My favorite commentary in the story is the "Search and Analysis" class.  It reminds me of how, today, rapid, online search and analysis of other people's work is unfortunately seen by many as more useful form of thinking.

They are, in effect, externalizing their cognition, offloading some of the difficult things to the collective (and this is very powerful, as Mike Villas and his friends demonstrate), but there is a tradeoff; we then lose the ability to do those difficult things, to internalize our thinking, and the story shows how this ability (such as the work of Dr. Xu) solved problems that confounded them.

By the way, the idea of the "critic" in the story is mysterious--it's only mentioned 3 times in vague contexts.  I wonder if the critic is a person that can still think internally and retains their mysterious "critical thinking" skills...

Fascinating, well-written story with many levels.  Thanks.

  Are you sure? yes | no

BigEd wrote 08/18/2018 at 14:13 point

Nice story! (By Vernor Vinge, who is always worthwhile.)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates