In what reads somewhat like a convoluted detective story, the events unfolding at the Chornobyl Exclusion Zone (CEZ) in Ukraine during late February had the media channels lighting up with chatter about ‘elevated gamma radiation levels’, which showed up on the public CEZ radiation monitoring dashboard for a handful of gamma radiation sensors. This happened right before this reporting system went off-line, leaving outside observers guessing at what was going on. By the time occupying forces had been driven out of the CEZ, the gamma radiation levels were reported as being similar to before the invasion, yet the computer hardware which was part of the monitoring system had vanished along with the occupying forces. After considering many explanations, this left security researchers like [Ruben Santamarta] to consider that the high values had been spoofed.
One of the major perks of all the affordable flight controllers and motors available from the hobby market is that you can really experiment with some crazy aircraft designs. [amazingdiyprojects] is experimenting with a coaxial helicopter design, with the goal off possibly using for a manned version in the future. (Video link, embedded below.)
The aircraft uses a pair of coaxial counter-rotating motors with large propellers, with several redundant control surfaces below the propellers. One of the theoretical advantages of this arrangement, compared to the more conventional quadcopter type designs, is redundancy. While a quadcopter will start tumbling when a single motor fails, this design will still be able to descend safely with just one motor.
It is also not dependent on the main motors for yaw, pitch and roll control. In multirotors, the motors need to keep a significant amount of the motor’s available power in reserve to increase torque at a moment’s notice for attitude control. This craft can use all the available thrust from the motors for lift, since control is provided by the control surfaces. There are five sets of redundant control surfaces below the propellers, each set connected to a separate flight controller.
Another advantage of this design is efficient for a given footprint, since one large propeller will always be more efficient than multiple smaller propellers. One of the goals for [amazingdiyprojects] is to fit the full size craft in a shipping container or on a trailer for transport without dissasembly.
On the 3rd of June 2019, a 1U CubeSat developed by students of the AGH University of Science and Technology in Kraków was released from the International Space Station. Within a few hours it was clear something was wrong, and by July 30th, the satellite was barely functional. A number of problems contributed to the gradual degradation of the KRAKsat spacecraft, which the team has thoroughly documented in a recently released paper.
We all know, at least in a general sense, that building and operating a spacecraft is an exceptionally difficult task on a technical level. But reading through the 20-pages of “KRAKsat Lessons Learned” gives you practical examples of just how many things can go wrong.
KRAKsat being released from the ISS
It all started with a steadily decreasing battery voltage. The voltage was dropping slowly enough that the team knew the solar panels were doing something, but unfortunately the KRAKsat didn’t have a way of reporting their output. This made it difficult to diagnose the energy deficit, but the team believes the issue may have been that the tumbling of the spacecraft meant the panels weren’t exposed to the amount of direct sunlight they had anticipated.
This slow energy drain continued until the voltage dropped to the point that the power supply shut down, and that’s were things really started going south. Once the satellite shut down the batteries were able to start charging back up, which normally would have been a good thing. But unfortunately the KRAKsat had no mechanism to remain powered down once the voltage climbed back above the shutoff threshold. This caused the satellite to enter into and loop where it would reboot itself as many as 150 times per orbit (approximately 90 minutes).
The paper then goes into a laundry list of other problems that contributed to KRAKsat’s failure. For example, the satellite had redundant radios onboard, but the software on them wasn’t identical. When they needed to switch over to the secondary radio, they found that a glitch in its software meant it was unable to access some portions of the onboard flash storage. The team also identified the lack of a filesystem on the flash storage as another stumbling block; having to pull things out using a pointer and the specific memory address was a cumbersome and time consuming task made all the more difficult by the spacecraft’s deteriorating condition.
Of course, building a satellite that was able to operate for a couple weeks is still an impressive achievement for a student team. As we’ve seen recently, even the pros can run into some serious technical issues once the spacecraft leaves the lab and is operating on its own.
We are somewhat spoiled because electronics today are very reliable compared to even a few decades ago. Most modern electronics obey the bathtub curve. If they don’t fail right away, they won’t fail for a very long time, in all likelihood. However, there are a few cases where that’s not a good enough answer. One is when something really important is at stake — the control systems of an airplane, for example. The other is when you are in an environment that might cause failures. In those cases — near a nuclear reactor or space, for example, you often are actually dealing with both problems. In this installment of Circuit VR, I’ll show you a few common ways to make digital logic circuits more robust with some examples you can run in the Falstad simulator in your browser.
[Logi.cals], a German software company focused on process, automation, and facilities planning has devised an automated wine decanting machine to demonstrate its logi.CAD 3 PLC programming tool. Sommeliers use these simple machines to handle heavy, expensive bottles of wine. [Logi.cals] added sensors and a stepper motor to a very nice looking specimen and automated the decanting process with a Raspberry Pi.
The outstanding feature of this design is the built-in redundancy. A pair of micro switches detect the presence of both a bottle and a glass. Failing these, a load cell is there to weigh the bottle, reporting naturally whether one is present. The load cell also plays a part in monitoring the liquid level in the bottle, as do capacitive sensors that register the wine flow. The design also includes strain gauges that measure the weight in the glass as well as the liquid level. To bring it full circle, they also verify that a glass is present.
[Logi.cals] used two expansion boards, the Quick2Wire interface with an I²C analogue board and the PiFace. The I²C analogue board takes information from the strain gauges over its ADC, and the Quick2Wire communicates with the load cell’s measurement amplifier over the serial connection. The PiFace handles the remaining sensors and the stepper motor, and provides high voltage protection for the Pi.
If you’re fresh out of heavy, expensive bottles of wine but have some cheap ones lying around, you could use a Pi to make them dance.
