December 17, 2017

Futaba replacement?

Well hello there dear old blog! It's been a while now. I haven't forgotten about you, I just haven't done much on the bench lately.

BUT. I did get myself a radio on the HobbyKing sale maybe a month back. Being a Futaba fanboy, I never expected that I would ever in my life buy a Flysky system. But now I have, I got myself a Turnigy Evolution. I've been looking at alternatives to the bulky Futaba, at least for the leasure flying I do at the office and now that it was on sale I ordered the Evolution at 35€, incluing a receiver.

60€ radio to the left, 600€ radio to the right

Ok. So, there's a small price difference between the 14SG and the Evolution. Don't get me wrong. The 14SG is a flawless radio, at least by the time it was launched. It has never ever glitched in the transmission and the telemetry was a great addition and quite unique in the price range before the Taranis arrived. I really love that radio.

But for flying quads, especially indoors I need two major features.

  • 6 channels
  • Voltage telemetry
And the Evolution has that. Yes, it has telemetry. And the receivers are dirty cheap. And the radio was dirt cheap. In fact, I think I can outfit most of my rotor crafts with receivers for the price of one single Futaba receiver. 

But how bad can it be? I'll get back on that if I have issues with it.

I will not forget to mention there are alternatives to the Evolution out there as well. One of them is the TBS Tango. It's a purpose built radio for quad racing and has some nice features in therms of programming. It is quite expensive, and comes without a transmitter. Which makes it ridicously expensive.

And coming up is a multi protocol radio called iRangeX iRX-IR8M. It looks like a knockoff of the TBS Tango and comes with multiple radio circuits built-in. I won't order one until there are some decent reviews online. My guess is that it will have a bit better gimbals than the Evolution and a poor feature set in the software. It's mostly the form factor, the basic telemetry and the multi protocol feature that will push this product.

October 14, 2017

"Fixed" the z-slop issue on my Fabrikator 2

So. I've finally worked out an extremely simple solution to the Z-slop issues I've had with my Fabrikator II.

The problem with the Z-axis is a combination of two issues with the printer.

  • The Z-backlash prevention mechanism is poorly designed
  • The Z-axis does not run smoothly and has to be forcefully pulled down by the Z-axis rod
The obvious solution would be to address those issues. And I have tried, but can't get the Z-axis to run smoothly enough.

What happens because of this is the there is a 0.2-0.4 mm slop in the Z-axis when it descends and then starts climbing again. This happens when the print starts (home, lift, descend to first position) and whenever a lift is done during the print. As an effect the printer will print 2 or 3 layers at the same height, causing the printer to print badly and the model to be of incorrect height.

So far I've only printed parts in the printer where the effects of this issue is not problematic. Which is quite limiting.

After a bit of googling gcode I realized I can solve the issue at the print start with only a bit of fiddling with the pre start gcode snippet. By default in Cura it looks something like this:

G28 ;Home
G1 Z15.0 F6000 ;Move the platform down 15mm
;Prime the extruder
G92 E0
G1 F200 E3
G92 E0

One of the important parts to notice here is the "move down" which on this printer is actually a "lift" part. It is when the printer comes down from this movement and starts moving up again that the problem will occur and the printer will put down multiple layers at the same height. So we can remove that line.

But the homing process will still have the same problem. The last movement of the homeing process is the Z-axis descending until the endstop swith is triggered. After this, the first 0.2-0.4mm of any up movement by the Z-axis stepper and rod will not result in movement of the print head. To counter this the entire build must offset to move the entire model up and prevent this initial slop.

This turned out easier than I expected. By using the G92 an axis position can be adjusted. This will introduce the offset needed and will effectively cause an initial lift of the given value. So I added this command as the last initial command before the print. The resulting Start Gcode now looks like this.

G28 ;Home
;G1 Z15.0 F6000 ;Move the platform down 15mm
;Prime the extruder
G92 E0
G1 F200 E3
G92 E0
;Set the Z-position with offset to counter fab2 z-backlash issue
G92 Z-0.2

This will cause my prints to turn out good and not need any further adjustments. The solution has two drawbacks.

  • The initial movement of the print head will traverse the bed at 0 height. This can cause issues, but might also wipe the nozzle. Which is not always a good thing if it happens at a less preferable location.
  • The print cannot contain any lifts. Prints that would benefit from lifts can still not be printer with this printer.
So. This solves my issue short term. But I should probably try to solve the mechanical issues as well to avoid this hack.

October 2, 2017

3 printers, 3 failures

I have 3 3D printers. I don't know how I ended up with 3 but here I am. I have 3 cheap 3D printers. And it annoys me. Cheap DIY printers are really good for learning. And I have learned a lot. But they are not good for every day 3D printer when you just want them to work.

Yesterday I was sketching a few parts for the kit of BRIO MEC that my children are playing with. I wanted to print a few simple pieces which do not exist in the kit and I think should be there to make a few new construction possibilities.

So I fired up my 3 printers to print 3 pieces at the same time. And I got 3 failed prints.

To the left is a piece from the Mini Fabrikator 1, which also goes under the name TinyBoy. What happened here is the build plate is sticking to the guide bars, and the belt skips. I had this problem in the beginning so it is not new. But it will need some work to clean it up.

In the middle is a piece from the Malyan M150. It is not visible, but the piece is warped. Not really the printers fault, this PLA material warps and I don't know why. Aside from the material issue here, what annoys me most about the M150 is that the bed is unleveling "itself" with time and I have to spend to adjusting it regularly. Not something you have time for every time.

To the right is a piece from the Fabrikator Mini 2. The main issue with this piece is that it is missing its first 0.5mm. Simply because the Z-axis anti backlash is flawed in design and the X-axis gantry is not running smoothly on the guide bars.

After this I will really start considering getting a better printer and selling/giving away some of the others that are to unreliable.

September 28, 2017

Bad day in the HGLRC factory

Zero fucks was given on that very day in the packaging department.

It's not even remotely difficult to put the board correctly in the box. Must have had a terrible day at work.

The board looks really great at first glance. Nice soldering and it is cleaned, which is not always the case with that china stuff.

September 19, 2017

FPV150 got 3 flights

The FPV150 was flying fantastically after the upgrade. But after about 5 minutes one of the ESCs started cutting out. I wasn't running low on voltage or anything and it seemed strange.

Anyway, to make a very long story short, it turns out it is probably faulty. I cannot connect to it with blheli configurator and I actually found in my old blog post that I had this problem with another ESC while building the first FPV150.

So I set out to order a new device. It turned out harder to find than I expected. I couldn't find one identical. Instead I ordered two ESCs from hobbyking with similar specs. I was quite surprised hobbyking didn't carry more variants of this small ESC. Any way, I got a Kingkong and a Multistar. Once upon a time I promised myself never ever to get a multistar again. They used to be real crap. But hey it's revision 16. Sixteen! Did they get it right this time?

I guess I'll find out in a few weeks once I get those props spinning again!

September 12, 2017

FPV150 revisited

Today I finally spent some time one the FPV150 I built a year and half ago. I was quite satisfied with the machine except for a few issues. First off, it sometimes does strange things while flying, like tilting and pitched. Second, the flight controller is mounted so badly it must be unscrewed to connect the USB wire. And the flight controller; well it's a CC3D.

I have noticed the stream of all-in-one flight controllers integrating more and more functions in one single unit. First off was the PDB, but then voltage sensors, current sensors and OSD chips have been added. Even video transmitter on the most recent ones. I got myself the "HGLRC" F3 V3.1. It is essentially some form of Seriously Pro racing F3 clone. I regret not getting the version with video transmitter while I was at it.

I started with a weigh-in. Always interesting to see how this effects the weight. I'll be ripping out three parts and putting only one back in to replace them.


Ok. Now let's open her up. I remember it was quite hard to get it together with all the wiring and boards crammed into the the body.


I remembered correctly. Inside I found a CC3D board in a small form factor, a "super simple" OSD board, a orangerx receiver of some kind. I had used the PDB that came with the Diatone frame. And a noname video transmitter. So I ripped out everything but the transmitter that I left on the top plate of the frame.


Left was only the motors and the OSD. After this image was taken, I also de soldered the ESC leads and removed the camera "assembly". Then I started putting her back together again. First off soldering the ESCs to the PDB. Well, the PDB means the flight controller in this case.


I picked this particular board because i got the feeling that they had made many iterations and improvements on it. This can always be fake and a noname product from China can be utter crap no matter what facade they try to put up. But I think they've gotten quite far with this one. It is made to be fitted in a racing multirotor craft of course, and as such has the wire leads for the ESC just like the motor layout in clean/beta flight. Only this detail is fantastic alone compared to board from the history of FPV racing. It also has easily accessible solder pads for the receiver, instead of trying to put together one of those microscopic connectors for the receiver.


And this is what it looks like with almost everything wired up. Neat compared to what it looked like a few hours back.

I put everything together. No big deal. I kept the buzzer connected to a PWM output on the receiver. This is simply because I've had very little luck with buzzers connected to the flight controller so far. So I'd rather not. After everything was assembled I weighed it again. I was only 2 grams down. Well, I checked the weight of the parts I removed and the weight of the flight controller and it was essentially the same. The 2 grams is probably due to a bit less wiring. Maybe the capacitor that I forgot to solder back on.

After putting everything together I realized there is a big hole on the bottom of the quad, exposing the flight controller. The PDB covered this hole before. 


So I printed a piece of plastic to cover it up.


Setting up betaflight took me probably 2 hours in total. Almost as much time as the build itself. It is simply because I ran into a few issues with the setup and the work went completely without hickups for once.
I had a big problem with the board not arming as expected and I had to do a few things to get it sorted.
  • Upgrading the firmware. Because at some point betaflight stopped displaying receiver signals in the GUI. Maybe betaflight updated in the background and I needed to put in a new firmware. I don't know why.
  • Lower the refresh rates in the PID. The board reported 7% load but the LED indicated overload. I have no idea why.
  • Set the min_check manually. When upgrading the firmware I used the "diff" command as recommended to store my setup. For some reason diff exported a min_check = 0. I don't really know why.
Feels like flight controller setup routine. I have no idea why, but I had to fix 3 things and now it works. I just hope it stays that way!

Footnote 1: I weighed my JJPRO 130 as well to see the difference. At 195 grams I understand why it barely flies. It is too heavy for flying with only 3-inch propellers. It was a big disappointment as it was a drop-in replacement for the FPV150 that I never took the time to fix.

September 9, 2017

i2c controlled RGBW LED strip controller

This is part of a internet connected playhouse that I have been planning and building ever so slowly during the summer. The system will eventually consist of a internet connected device (ESP32), battery, solar panel and charger and some lighting installations in the childrens playhouse.

On the porch, I'm planning to install LED strips along the sides to fill the porch with light of selectable color (or even with special effects). It will be controllable both over the internet as well as using a wall switch. Part of the challenge here is to connect the device to the internet, or via something to the internet.

I chose to build a separate device for this purpose instead of integrating it in the main controller. This device will only drive the LED while controlled over the i2c bus from the main controller. There are many many guides on building your own LED controller but I have yet to see one about i2c.

Anyway. I started out with adafruit article on the matter. They make great simple articles and being not so skilled in electronics I was mainly looking for some ideas on which transistor to use for the task. I managed to get the transistor recommended by adafruit from ebay. Ebay is like the only simple source for buying electronic components in small quantities. I read the specs in the FET in question (IRLB8721) and I must say it is massively over dimensioned for my requirements. But I guess it will do.

i2c rgb controller, first setup
Early stage of the RGB LED controller.

As always I started with a first build on the breadboard just to see it working. I also did most of the programming at this point. On the picture is a second arduino sending a sequence of RGB commands to the controller for testing purposes. Worked well and turned out quite simple.

i2c RGB controller
LED controller, disconnected because the light messed to much with my camera.

Next step was to make the controller more compact by building it on a experimental board. This is probably about as good as it gets with my skills and tools. I've moved from a Arduino Nano to an Arduino Pro Mini. It's a bit smaller, mainly because it does not have a USB connector. Instead you need a USB UART/ISP (often incorrectly called an FTDI). Might seem scary, but once you've tried it it is not that bad.

I also had to add a buck converter as the strip I'm using is powered by 12 volt. I added a screw connector for the 12V power and JST-XH connectors for both the LED itself and the i2c connection. I've made a simple i2c bus connection hub previously to connect the devices in the playhouse together.

It all turned out quite good. The only main problem I had is that I cut off the LED strip to solder the wire to the newly cut end. This did not work out well since the light cutting and soldering seems to have damaged the printed copper surface of the strip. This turned into an intermittent lightmare (pun intended, I'm a dad, it's ok!).