Current Status

I've spent about one year programming the core systems, and one year building, and it is now in the final stages of writing/perfecting the highest level algorithms and adjusting for real-world use.  The packet radio interface has been tested on-the-air and does work.  The PBBS system and APRS beacon has been tested in simulation (and works), but hasn't yet been tested over-the-air.  The TROT drive system has been tested on the indoor test frame, not in use outside on actual trees or weather conditions yet, but much of it is still under manual control.  The full size 2m/70cm antenna is only theoretical at this point but is simple to build, something I have left to the very end, but I will need to add an appropriate female SMA bulkhead adapter to extend the 50 ohm terminal outside the Radio Box.  The THUMP system is only about 50% completed, as the SIMTHEO algorithm does work, but inverting it and adapting it to the tethered accelerometer interrupt is mainly theoretical at the time of this writing.

All electromechanical systems are functioning, and I have created a large set of XMPP commands to manually control the craft and read its sensors, but there are only a few autonomous robotics systems in place at the time of this writing.

Working autonomous robotic systems

• Solar Charge Mode:  The power regulation microcontroller (Huckleberry) can automatically monitor the voltages of the craft's battery banks and switch the craft's systems from one to another to charge one bank while using another.
• Orbital Mechanics:  The Planetary Mass can slow start and park at different positions corresponding to sunrise, solar noon, and sunset.
• Gyrofan:  The gyro can perform slow starts and hold itself at a specified RPM, using 3 Hall-effect sensors in conjunction with a quad comparator, increasing energy to hold its position by varying PWM and/or switching to different drive modes.  Although, due to a freak coincidence (explained later) the gyro BLDC motor windings overheated to the point where the motor has seized up and I have ordered a replacement, but have not yet soldered it in place.
• Pitch and Roll angle--The system can compute the Pitch and Roll angles to within around .1 degree by calculating its angle with respect to gravity.

Autonomous robotic systems that still need to be implemented

• The system can solar charge itself, as mentioned above, and the CdS cells can read light levels, but I haven't yet applied Lambert's cosine law to estimate the angle of the sun and have the unit automatically set itself to that angle. I still need to line the LDR Tubes with an opaque material to prevent light leakage through the translucent PETG plastic.  This angle should be used by the Motor Control ATtiny (Sawyer) to reposition itself automatically, incorporating its internal timer.
• The Pi needs to use the accelerometer data to increase the precision of the solar angle set by Sawyer.  If the Pi goes down, Sawyer can act independently.
• I have not added active pendulum stabilization algorithms via the planetary mass or the gyroscopic reaction wheel (this is a luxury item that can wait until later).
  Sign-Magnitude and Locked-Antiphase PWM are working, but the Planetary Mass orbit still needs to automatically switch between modes depending on the point in the orbit.

Results of testing so far:

Negative

• The Gyrofan clearance is too tight in the fan duct and Circuit Board C.  The wiring channels are too narrow.  This makes it hard to assemble.
•  The Gyrofan is ineffective at the speeds that I have tested.  I have not fully loaded the gyro mass, but I don't want to add any more, as it decreases the max solar panel tilt angle (which is already borderline).  But I am afraid to run it at faster speeds at this point (I don't want it to disintegrate and damage Circuit Board C).  Once the other algorithms on the craft are added and documented, I may try ramping up the speeds to see if I can get appreciable stabilization from the gyro.
•  The weight is the primary issue, period, being at 8.28 lbs (3.76 kg)  If the craft was lighter, it would have higher elevation and the gyro would be more effective.  The tether axis (Y-axis) needs to be offset to correct a multiplicative feedback effect that is occurring with the gyro.  The weight also makes the craft fragile.
•  The first prototype turned out to be more expensive than I expected, at $390 US dollars over the two-year span, as the individual parts, while relatively inexpensive, began to increase the total cost as I added more of them.  This cost could be lowered in the future, since I now have a better estimate of the requirements.
•  The dead-bug style electrical wiring is fragile and a fire hazard, especially in conjunction with the high amperage circuitry.  There is some overcurrent protection, but not enough to stop a high-temperature short.  A smoke detector needs to be to be kept near the unit.  Ideally, everything should be constructed using printed circuit boards and modular wire connectors but this was impractical and expensive for me for my first prototype.
•  The first BLDC motor that worked so well during indoor testing for months stalled and overheated after a freak cascade failure when I took it outside in the sunlight in late March 2018.  During indoor testing, I used a 500 watt halogen light to simulate the sun, and it kicked on power to both ATtinys (Sawyer and Huckleberry) and also the ESP8266, which worked as designed.  But during actual testing in the sun, as I was moving it around changing its angle and encountering shade from the tree branches, the light hit the panel intermittently, causing the solar controller and its 5v regulator to kick on and off quickly.  And one of these intermittent start voltages suddenly locked up 3 microcontrollers simultaneously, causing their default GPIO states (that I had set via programming) to fail to activate.  This allowed some of the MOSFETs to spontaneously turn on:  the high current battery power suddenly kicked on via Huckleberry (and removing it from sunlight wouldn't turn it off), and the BLDC also spontaneously kicked on via Sawyer (and remain fixed in a stall condition, quickly heating up).  I have stall detection present in Sawyer, but it wasn't working since the chip was locked-up.  If that wasn't enough, the ESP8266 also went into an lock-up state causing the Raspberry Pi to spontaneously boot up.  I could access the Pi, yet I could not quickly issue any commands fast enough to turn off the power before the motor windings burned up and seized up the rotor, as I hadn't programmed any aliases beforehand.  I quickly opened up the case and cut the battery leads to shut the thing down, but it was too late to save the motor.  So I've ordered a replacement BLDC motor but have not yet soldered it in place.  To prevent this issue from re-occurring, I will have to turn on the ATtiny's brownout detection and add additional checks to ensure their default states are reliable.  I was hoping not to have to use many external pulldowns, as they still won't prevent a programming error from overriding them.  The ATtiny microcontrollers are usually very reliable devices, but you have to give them reliable power.

Positive

•  I am happy that so far, my custom H-Bridge and microcontroller hasn't burnt out when driving under high loads using sign-magnitude and locked-antiphase PWM.  The logic-level MOSFETs are more sensitive to over-voltages.  I added an RC circuit for hardware level shoot-through protection and large smoothing capacitors and they seem to be working.  The ATtiny which drives the motors no longer sporadically resets after I added the capacitors.
•  The Lithium-ion batteries don't seem to deplete when the craft is powered down, which is good.  MOSFET and ADC leakage seems fairly low.  I have to be very careful to avoid draining them too low, since I've bypassed its charger board and am pulling from the cells directly.
•  The Qi Charger seems to work even though it is pushing near the max current limit of the 5v DC boost converter and the Nexus 4 smartphone lines up well to the dock.
•  The Packet Radio PBBS in simulation is really fun.  I can perform mock communications between XMPP on the smartphone and a remote packet station, and it just has a neat feeling.  I can't wait until I can someday put it on the air.
•  Controlling the craft via XMPP commands and viewing its status using the XMPP presence works very well.  It's fun turning off the Pi WiFi and the Pi itself using the ESP8266 via XMPP to save battery power when they are not needed.