I think I've arrived at a stage where I can show a bit of what I'm, working on, both as a teaser, and as a commitment for my self to make the teaser a reality ...
So, after several hours teaching myself Solidworks, I can show off the following image:
Working-name for the project: OpenCoreBot, or OCB. More details to follow when I'm closing on completion of the design.
After reviewing the naive errors in my thinking (see previous post), I've concluded that my idea for simplifying the belt path will not work. So, a revised prototype has been built, now using 3D-printed belt idlers on the loops, and only straight & symmetric lines on the essential parts of the belt path.
So, I'm no longer chasing the not-crossing belt path, instead going with a conventional, two-level CoreXY. There is now a crossing path on the belts, but the belts run on two separate levels, so there is no parts where the belt is forced to move in ways it's not designed to do.
After building my first prototype of a CoreXY based cartesian movement system, as shown in two earlier posts 1)CoreXY Experimentation2)CoreXY experimentation update, I have realized that my idea for a simpler pulley configuration is flawed. I've simply forgot basic geometry math. The idea was to start with a CoreXY system, as described on http://corexy.com, take inspiration from FABtotum to avoid crossing belts, and simplify the pulley location to get as few anchor poins for the belts as possible. My attempt used two "layers" of belt paths, and tried to reduce the number of pulley-axles to 4, compared to CoreXY's 8 and FABtotum's 6. But, unless I start offsetting the location of stepper motors (and introducing uneven stress on the frame), I end up with an undesired geometry...
This week I re-launched my blog, and I really wanted to do so silently, without the useless "Oh look, I've upgraded" type of post that so many publish (including myself in the past). But I was hit by a very common abuse-vector that prompts me to write a few words about it. The problem: DoS via WordPress XMLRPC. I've installed WordPress 4.0, a version where flaws in the XML-RPC mechanisms allowing it to be used as part of bot-nets and the like are supposedly resolved. But, after having my new WP installation active for less than 24 hours, my server ground to a halt, with ridiculous load numbers (190+ load), all caused by accesses to /xmlrpc.php
What is XML-RPC anyway?
The XML-RPC API is used by WordPress for a few things. The useful part, is making third-party publishing and administration applications for both desktop and mobile. But it is also used for so-called "pingbacks" and "trackbacks", where WordPress itself notifies other WordPress installations that links to their content has been created in articles/posts/pages. As this mechanism is supposed to run without user intervention, it's done without authentication, unlike the third-party client enabling admin/publish features of the API.
Insecure by default
Before WordPress 3.5, the XML-RPC API was something you had to actively enable. So to be able to use the API for publishing clients and/or pingbacks and trackbacks, you had to be aware of that the API existed, and enable it. For a number of reasons, I think that was a really good idea. Perhaps primarily because the XML-RPC used to have some seriously big flaws that could be used as vectors for abusing a WordPress installation. Now, from version 3.5, most of these flaws have been fixed. And with that, someone decided that users of WordPress are not very bright, and having to enable an API before using a third-party client was very complex and too hard for the users to understand. So they enabled the API by default. And removed the option for turning it off easily! How can possibly having an open API for anonymous, un-authenticated generator of HTTP-requests enabled by default, with no filtering, be a bad idea, right?
The prototype for my CoreXY experiment now moves by motor control. Using Marlin software on an Arduino Mega with RAMPS1.4 to drive the motors, I go through several speeds from 800mm/min to 24000mm/min, (that's 400mm/sec) moves. I have made no care to precision in the belt, and adding that to unevenly tightened belts, flex in components, and finally a pen that's not really fastened well, there is noticeable flaws in the resulting drawing. However, this also means the prototype highlights what areas of a final build will need extra attention.
Based on the CoreXY concept and ideas from FABtotum to avoid crossing belts, I'm experimenting to see if I can get away with as few mounting-points for belts/pulleys as possible. This video shows that my prototype moves, as well as showing the CoreXY movements. Moving resistance feels very low, even if this is very simply built (no linear rollers/brass bearings, no attention made to precicion...). Next step: moving the parts using the motors
Finally I've gotten stable Loiter, by getting GPS and Compass away from pesky annoying interference. I wasn't able to show long-duration position hold as I had planned, because my battery went flat a bit early
The AC version I am using is quite old, so it is not representative of current AC Loiter state. I have also done minimal tuning of nav/loiter when doing the test.
The frame I am using is a HobbyKing Q450 (really a Whirlwind FY450), equipped with generic 20A ESC's and NTM 28-30S 900 motors spinning unbalanced 1045SF plastic props, so the PX4 is seeing quite a lot of vibration. The GPS is a uBlox Neo-7M + HMC5883l compass from HobbyKing: http://hobbyking.com/hobbyking/store/__55558__
Maiden flight of my first bujild of a tricopter. The build is based on the common rcexplorer.se / David Windestål trike-design, but using aluminium 10x10mm profiles, FR4 as material for center-plate. Flight controller on this one is a KK2.1.5, ESC's are HK SS-series 18-20, tail servo is a TGY-9018MG.
Evening flight in November at Biri Bruk.
Aircraft is my HCopter APM2.0
Soundtrack: "Son of a Rocket" Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 http://creativecommons.org/licenses/by/3.0/