Archive for the Robotics Category

Propped up!

Posted in 3D Printing, Hardware, Robotics on May 31, 2020 by asteriondaedalus

So I bought me 6 of these 50mm EDF some time ago. Should have waited, of course, since I really needed 2×3 each of CW and CCW units for my blimp project (based on a pool toy LOL).

The problem then how do I sort out the need for contra rotation to try to balance torque forces?

3D printing fans was the solution!

The bottom left fan is the original. The two on the right tests. The original code for the fans was provided by someone else. Note I did have to modify the code a little, since the source code had some design features that were not needed and also I had to add a disc with hole for the hub attached to the motor. You can see one test with a blade broken off? That was interesting, there appears to be a print phenomenon when the hug wall is too thin and the print does not weld the blades to the hub. Increase the hub thickness and the problem corrects itself.

To get CW and CWW I could run the OpenSCAD software twice BUT you can also mirror the STL file in the Flashforge software.

The problem might be that to be truly reversible, the thread on the hub for the nut should be in the opposite twist, since you always want your rotations tightening the nut. The fit of the printed hub is, however, quite snug and a dab of epoxy would aid and abet the retaining of the nut I suspect.

I was going to start with drive motors in the same config as for the SAAB Double Eagle. These appear aligned so there centre lines meet aft somewheres. For cruising rather than for fine manoeuvring per se. They make a lot of sense, since the lever arm with respect to the CoG is increased from where it would be, if the motors were lined up on the main axes. This then amplifies the turning force of the thrusters, so they can steer with greater effect. Or so I surmise. I haven’t found a paper explaining the configuration … yet.

So, I will use 10mm OD carbon fibre tube to build a frame to attach to Nemo (ROFLMAO) and here is the stl.

Not bad

Posted in 3D Printing, Robotics on May 4, 2019 by asteriondaedalus

So, I did a print of the wheel hub. It turned out I tight fit. Too tight to insert the motor without having to sand the inner surface of the collar that will hug the outrunner.

I snuck back into the model to shave a tad off for the next print. The collar will help fit the wheel square onto the outrunner to prevent wobbling.

Balancing Act

Posted in 3D Printing, AI, Hardware, Robotics on May 4, 2019 by asteriondaedalus

So, I have printed the carcass of a 3d printed balancing robot.

I bought two gimbal motors.

I have my pesky gimbal controller from my lidar experiments.

Go figure, you can buy rock crawler tires for my old Venom Creeper for $5 a pair, so I opted for an indoor/outdoor self balancing robot. To fit the crawler tires I grabbed a 3D model of a beaded 2.2″ rim. I then modified it with freeCAD to fit over the gimbal motor – including a collar to fit around the outboard spindle.

I will mate the gimbal controller with a Sipeed Dock M1W to give the balancing robot autonomous smarts. Especially with the wifi link, it can still lean on more smarts off-board.

Give me a break!

Posted in Robotics, Sensing on March 8, 2019 by asteriondaedalus

So, you know the story behind OpenSprinklette.

Why bother with an raspingdoodleberry Pi and a “open” hardware controller for sprinklers of the OpenSprinkler, for $200 all up, if you can build a controller for sub $20 using a UNO based ESP8266 with a quad relay board, or a nest ESP8266 with single relays.

Well, StarGazer is US$980! Or, at current rates, AUS$1,390.91!

When all you need is a OpenMV M7 at $60, with a bunch of printed April Tags. Oh, and some trigonometry.

Two OpenMV M7 on their way to my parts bins.

My CMUCAM5 Pixy is getting old, but I wonder if I can sneak some of the OpenMV libraries over to the CMUCAM?

My PX4FLOW is looking sad. This is because its the same price breakpoint as the OpenMV M7. The PX4FLOW is only for Optical Flow tracking. The OpenMV can be used at least for Optical Flow, but also for a range of other applications as noted on its web page.


Posted in IOT, MQTT, Processing, Robotics, ROS on July 23, 2015 by asteriondaedalus

I found that Processing has a library for talking to MQTT so …

Will make sense when I get the 360 degree obstacle thingy going as I should be able to send “left a bit” … “righ a bit” messages to the MQTT server etc.

MQTT has much the same topic based thingy as ROS yes?  Well, sort off.  But golly, to be free of ROS, only in as far as you can work off the IOT as well – and there is likely a ROS-MQTT bridge in any event.

Better yet, it works on Processing for Android! Whooo hooo!

Now, I am in comms with the author of BOOFCV as we type here to sort out why the BOOFCV examples are not compiling for Android Mode.  Hmmm.