Sunday, October 22, 2017

Robot Problem Solving - Gearbox Slipped a Cog

The "Rat" has become difficult to control in the last 3 weeks. It has the common mini wheeled robot setup of 2 x yellow plastic motor-gearbox units - one on each side with direction controlled by running them at different speeds. In the last 3 weeks it has become impossible to run forward in a straight line but it is OK in reverse. We have put in a lot of time on detective work and researching more complex designs.

I tried replacing our simple H-Bridge analogue power circuit with a more complex digital solution involving an Arduino Nano microcontroller giving PCM outputs from our screen light patch LDR circuits as analogue inputs. That gave even more random out of control crazy movement. And the power amplifier board gave an unpleasant noise from the PCM frequency even with motors disconnected. [EDIT - LATER 28 Oct 2017 - discovered the need to use "float" when doing some of the calculations on analogue inputs - this Arduino Nano solution is now looking better. The unpleasant noise issue remains.]

I also looked at

Suspicion then fell on the motor-gearbox units. The left one did feel harsh and rough turning the wheel to spin up the motor compared with the smooth feeling of the right one. But why would it be OK in reverse?

I bought 2 new units and swapped them in. The "Rat" was controllable again. Repaired! Hooray!

I then investigated the old units. I replaced the motors thinking maybe we had given them too much power and done some damage. The motor swap is relatively easy because the motor is only held in by an elastic plastic strap held by 2 hooks. That made no difference, the left hand unit was still harsh. I inspected more closely and it felt difficult to push the left motor into place while it was smooth to push in the right motor. So I pushed the left motor cog about 1mm along its shaft closer to the motor body. Smooth action!

"Slip a cog" is an old school metaphor for technology going wrong. But in the case of our robot that literally is what happened! I hope it is useful to share that this very common unit can develop a harsh drive problem and adjusting the cog position on the motor shaft can fix it.

Tuesday, September 26, 2017

SmartWatch as robot brain?

Our robot story so far has been about smartphones as robot brains. We want to make small robots and smartphones are a little too big. So here's looking at you, smartwatch. 30 dollars including postage buys a DZ09 smartwatch.

Photo: With straps removed and placed beside a smartphone:

Photo: On removing the straps I discover that the antenna is inside part of the strap.
So it gets this board mount:

First tests and impressions:

  • Works with a Vodafone NZ SIM card, in that I can send and receive txts. 
  • With the straps removed, to get a reasonable touch response, I need to also hold or touch the metal casing.
  • Needs a micro SD card before showing any storage space when connected with USB.
  • Good camera placement for a robot animal head. It looks out the top end parallel to the screen surface rather than at the usual 90 degrees perpendicular.
  • The "browser" icon starts an installation from the Internet. This "Library Update" ends with a message: "Net busy". I am trying variations on the "APN" configuration setting for Internet via cell network but with no result yet.
  • After much searching and reading, I am not sure if this is running an "Android Wear OS" or a "Nucleus OS". First experiment will be to try to program it with the Android Development Kit and see how far we can get.
Photo: of me taken with the DZ09:

Tuesday, September 12, 2017

Publication! - XMRemoteRobot - our open source remote control server software

XMRemoteRobot is published on "GitHub". XMRemoteRobot is web server software that enables Human Commanders to remote-control devices in real time over the Internet.

XMRemoteRobot is a spinoff from learning, teaching and research at the Manukau Institute of Technology. XMRemoteRobot is focussed on being small and efficient for our particular robot remote control and telemetry needs - which may be your needs. The code is written to be clearly understandable so it can double as an education resource for the new ASP.NET Core technology. You can support this by giving feedback, comments and suggestions.

XMRemoteRobot has an online demo. Web page to web page on a screen split by an "iframe" is a good simulation test.

Video of XMRemoteRobot in action with our "Creative RAT" robot vehicle:

Thursday, August 31, 2017

ATtiny85 Microcontroller - first impressions - excellent

For running motors etc from mobile phones I have been going "old school" analogue with early success with "robot rat" and having a lot of challenges with "robot snake". I had thought that a microcontroller approach would be complex and expensive. This is where the cellphone is the robot "brain" and with one or more microcontrollers as the "spinal cord". I found ATtiny85 boards selling for NZD 3.50, approx USD 2.30). I followed the instructions and everything worked, smoothly and easily. I had the first example program running on this ultra micro computer in 1 hour and I was running my own after another 20 mins.

Excellent instructions on how to program using the Arduino IDE:

Only advice I would add is that I found it best to stop a program run by pulling out the USB cable and let ATtiny85 go dead for a few minutes while writing the next one - then plug in after starting the new program on the PC. The instructions suggest briefly pull it out and plug it in again when we  run a new program but that gave errors which went away when I did the longer disconnect.

I  am interested in using ATtiny85 to run hobby servos.
I run my first code "sketch" (see below)  - and it gives me 2 pieces of good news:

  1. the "delayMicroseconds()" method works on an ATtiny85
  2. although "delayMicroseconds()" specifies "unsigned int" as the data type, I found it was working OK with common ordinary "int".

int m = 16000;

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(0, OUTPUT); //LED on Model B
  pinMode(1, OUTPUT); //LED on Model A  or Pro

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(0, HIGH);   // turn the LED on (HIGH is the voltage level)
  digitalWrite(1, HIGH);
  digitalWrite(0, LOW);    // turn the LED off by making the voltage LOW
  digitalWrite(1, LOW); 
  delay(3000);               // wait for 3 seconds

Wednesday, August 2, 2017

Programming Mobile Phones - Revisit, Review, DroidScript looking good.

An intense weekend programming the test Android Phone. I was making slow progress with the cross-platform tools: Cordova and Xamarin. In the meantime I have been finding that I can prototype a lot of what we want to do with conventional web pages stored on a webserver not needing phone app programming at all.  I need a simple framework, where Android-only is OK, and framework can add phone functions value to my HTML prototypes.  I did a more in depth look at "DroidScript"and it is looking good. I began by trying to work out from the documentation how it could work with an HTML-based user interface, That was inconclusive so I ran it and found immediately that it offers an "HTML App" option which meets my needs very well.

In principle "DroidScript" is like a simplified "Cordova" but "DroidScript" keeps it simple by only supporting Android. The "DroidScript" IDE (Integrated Development Environment) runs completely on the phone although we can run it from a PC via a web interface using a WiFi connection. This lets us drive "DroidScript" with a full screen and keyboard. The IDE is remarkably capable considering it is a download of only 8 Meg compared to the multiple gigabytes of its rivals. It is a good fresh experience to make small edits then test run instantly.

The "HTML App" experience is of an HTML web page, with JavaScript blocks just as we would expect with standard web pages. The only remarkable element is a script import of "app.js" which turns out to be the interface into the phone functions. So it is a very familiar environment with an extended JavaScript which is highly phone capable.

The authors of "DroidScript" are interested in robotics and have done work on getting robotics support into their APIs. "DroidScript" has resources ranging from community contributed sample apps to paid plugins.

"DroidScript" has a home website and an online wiki, but I found it was best experienced, including documentation, by running it on the phone while remoting from the PC. "DroidScript" is a free app from the Google Play store. There are some paid plugins or enthusiasts can get these and support the project via a premium subscription model.

Thursday, July 27, 2017

The Mocket - Weight saving - old small cellphone (no) and back cover removal (yes)

The Challenge - from our previous exciting episodes, the "weight allowance" for construction is est 134g.

Idea? - use an old smartphone Vodafone 858 that is smaller than number one tester - a current Vodafone VFD-300.

Out with the weighing machine.
The old 858 is 99g complete and 69g minus battery and back cover
The new VFD-300 is 103g complete and 65g minus battery and back cover.
I had not thought of flying without the back cover until now but I get that idea from doing this exercise. Minus back cover does look possible, maybe with cling wrap as a dust cover, and it saves 10g for the VFD-300. The construction weight budget goes up to 146g.

Change Sun 50mm Ducted Fan 66
Hyperion Battery 3S Lithium Graphene77
Hobbywing Flyfun 30A ESC Controller26
Vodafone VFD-300 Mobile Phone65
2 x Chihaimotor Geared Motor 20

Friday, July 21, 2017

The Mocket - design - "top heavy" is good for rocket stability

"The Mocket" is a model rocket in shape and appearance, but the motor in the tail is an electric "fan-jet". Similar thrust source and direction can get us started on flight control problem solving.

The current plan is to place most of the weight eg battery, mobile phone, into the head and have a mostly empty middle section to get the height up to 1m. Why weight at the top - isn't that top-heavy? Why give it extra height - wouldn't it be better to make it shorter to save weight?

In this video, John compares this with balancing a 1m rod on his finger. Adding the weight of a mobile phone at the top gives more stability because of inertia and leverage effects.

Note that The Mocket will not have tail fins because (1) it will not move fast enough on the way up to be able to use air pressure as a stabilising force, (2) it has fold-out "head fins" which act as air brakes on the way down and tail fins would work against these.

One of the many experiments for The Mocket is to try to keep it on a straight-up course by angling the motor, rather like a finger balancing a 1m rod. And rather like a SpaceX Falcon 9.