XMRemoteRobot - movement achieved with "inchworm gait"

Snake Robot hardware milestone today -  reliable ongoing operation responding to servo commands. Now we have a testbed, the first programming exercise is the "inchworm" gait which is the simplest of snake robot "gaits".

The biggest challenge in the last 3 days has been the head section intermittently going dead as its Arduino Nano microcontroller resets itself. After a lot of detective work I tracked it down to momentary voltage drops. The power supply to the forward section was through thin wires that gave a voltage drop from about 5.3V to 4.8V. There were extra momentary voltage drops when servos came under load and that caused the microcontroller resets. The fix was to run a second parallel pair of wires, V+ and GND from the regulator on Rib05 to the power board on Rib02. That may not be the full story because adding these similar thin wires resulted in a minimal voltage drop rather than halving the effect as expected. It is therefore a good idea to check sections in detail for an unexpected resistance effect.

XMSnakeRobot - waggles its head and tail

Youtube video. Testing starts with hand-typing simple command signals.

XMSnakeRobot - we have digital control - 20 out of 20 servos responding.

Milestone tonight (Tue, 26 Dec 2017).
The snake robot "spinal cord" is working. That is 20 servos are responding to remote signals as planned.

Looking at my previous issues of "rogue" servo movements.

Try changing from Arduino Nano to Wemos D1 - a different microcontroller.
I did that - a major change, and the servo bad behaviour was THE SAME!. This prompted me to look harder at my code. After digging deep I did find a "bug". Coding fix gave a successful system fix.

Working on other issues.

Issue: One Arduino also resets itself when servos encounter loads like lifting the snake robot's head.
That head section has 40cm of thin cables supplying power from the centre of the Snake Robot. These have a significant voltage drop - typically 5.1 volt dropping to 4.8 V with momentarily dropping lower when servo loads kick in. 
I got a small improvement by cranking up the regulator to 5.4V. 
I got a further improvement by adding a 470uF capacitor and 39 ohm resistor to the Arduino Nano power supply cable - all good on individual servo testing [LATER - resets still happening on multi-servo movements trying out movement "gaits"]

Hypothesis: Try the "volatile" coding keyword for my servo array.
Made no difference. Also "volatile" triggered a compile error with the Wemos board. That puts a stop to trying "volatile" because I want to leave the way open to using Wemos boards.

Photo: Snake Robot as at 26 Dec 2017.



















Photo: The Android Smartphone is running app "Serial Bluetooth Terminal" by Kai Morich.
Signal "A2+020" = "Target microcontroller 'A', Target Servo 2, Set to +20 degrees from centre position."

XMSnakeRobot - HC-05 problem solved - needs clean switch-on

Keywords: HC-05, problem, erratic, will not switch on, fail, dead, intermittent, fault, electronic module.

On changing to an external power supply I found that the HC-05 module would not start when I "switched on" by connecting an alligator clip. Then I observed that if I touched the alligator clip to the battery terminal the HC-05 would switch on OK. But the usual clamping it on - no! After some playful experimentation I found a consistent pattern. The HC-05 needs a definite clean change from off to on. Clamping an alligator clip gives a moment of touching and movement which gives an on-off-on-off-on-off-on way of starting electrical life in my circuit. I should solder a proper switch into the snake robot external power leads. In the meantime I have worked out an alligator clipping action where I open the alligator clip, press one side against the terminal then release the other side to clamp.

Hopefully this helps anyone else encountering this mystery!
What is an HC-05? A small circuit board about the size of a human little finger which gives bluetooth capability to device projects - like a snake robot. More about HC-05 here:
http://howtomechatronics.com/tutorials/arduino/arduino-and-hc-05-bluetooth-module-tutorial/

XMSnakeRobot - Servo issues - 13 good channels - 7 do strange dancing

The snake robot -  (link) see photos here - has 20 servos run from 3 x Arduino Nano microcontrollers. As of today 13 of these are working and 7 are mis-behaving. Most common misbehaviour is:

• Command servo to turn 30 degrees - it turns more than that.
• Command servo to return to the centre position - it turns in the same direction as before but to its extreme position.

My Arduino code includes code to return all servos to the centre position on reset. This works.
I have tried swapping servos and found that the behaviour is pin-related rather than servo-related.
All 3 Arduino Nanos have the same "sketch" (program code) and similar servos connected. They are misbehaving on different pins.
One Arduino also resets itself when servos encounter loads like lifting the snake robot's head.
[Later - 26 Dec 2017 - that head section Arduino has 40cm of thin cables supplying power. These have a significant voltage drop - typically 5.1 volt dropping to 4.8 V with momentarily dropping lower when servo loads kick in. Fix was to crank up the regulator to 5.35V (small improvement) and add a 470uF capacitor and 39 ohm resistor to the Arduino Nano power supply cable (complete fix).]

Hypothesis: There is a problem with I2C.
I have been trying I2C for the first time so I have put a lot of time into checking that.
Now I have changed to Serial communications with exactly the same effect continuing.
At least I know that I can get I2C to work!

Hypothesis: Servos can cause electrical interference.
I have tried running an Arduino on a separate battery to the Servo power supply. No difference.

Hypothesis: Arduino Nano work overload.
TODO try the  "volatile" coding keyword for my servo array.
The (link) Arduino Reference "Volatile"  - states:
"volatile" -- "Specifically, it directs the compiler to load the variable from RAM and not from a storage register, which is a temporary memory location where program variables are stored and manipulated. Under certain conditions, the value for a variable stored in registers can be inaccurate."
Emphasis mine!
[Later - 26 Dec 2017 - made no difference. Wemos board (see below) would not compile so "volatile" is eliminated because I want to leave the way open to using Wemos boards]

Hypothesis: The Arduino Nano is simply too low powered to handle the work I am giving it and it is "falling to pieces under the stress". I have found this forum comment:
(link) desmondcorreia (2011) writes:
I have tested each code independently everything works fine but as soon as i put it together everything goes wrong.
Desmond, You sum up my experience so well!
I do have a WEMOS D1 microcontroller where the specs say it runs at 80 MHz which is a good advance on the 16 MHz of the Arduino Nano. I am considering swapping that in. A little challenging with it being a 3.3 Volt system connecting into my very 5-volt-everywhere snake robot.
[Later - 26 Dec 2017 - changed tail section microcontroller from Nano to Wemos, a major change, and the servo behaviour was the same. This prompted me to do another review of my coding and after digging deep I did find a "bug". Coding fix gave a successful system fix.]

That should be enough to be going on with!

XMSnakeRobot - Good news for current draw. I2C partly working

First results from the ammeter on current draw for this design.
0.5 to 1.0 A depending on servo activity which is however low at this early testing stage.
This is good news as it is less than expected.
One concern was that segments as they move would place nearby segments under load and put servos into a "stall" state where they draw 0.6 A. This is not happening like that. What I am observing is servos under load but responding with rapid "buzzing" correction attempts which average out to a much lower current draw.

-----------------------------
In the previous post I wrote:

Searching .. From Arduio forum thread "I2C with internal pullups"
https://forum.arduino.cc/index.php?topic=369003.0

"Koepel" says: "If  an Arduino is Slave, and it has the power turned off, that will keep the SDA and SCL low via the diodes."

"Koepel" is right. Connecting the "slaves" for a complete test setup gets my servos responding to signals sent via I2C. Unfortunately the responses are not 100 percent reliable. One of my 2 "slave" sub-systems is ok on 7 servos out of 8 so I will inspect that servo. The other "slave" sub-system gives a correct response to less than half of the signals I send. These "slave" sub-systems are built to be almost identical and they run on the same I2C common wires so this is a mystery. I plan to continue with I2C by working for half a day focussing on testing servos - then if not reliable it will be plan B which is to replace I2C with Serial and SoftwareSerial.

Signals explained by example:
"A2+030" - Arduino Nano A, Servo 2, set to 30 degrees from centre position.
"B0-020" - Arduino Nano B, Servo 0, set to minus 20 degrees from centre position.
"C5+000" - Arduino Nano C, Servo 5, set to centre position.

I type these signals into an Android Cellphone running a Bluetooth Terminal app. The snake robot receives these on an HC-05 module which feeds them via Serial to "nano" microcontroller "A". If the signal starts with 'B' or 'C' that microcontroller uses I2C to pass them on to the other "slave" microcontrollers. Photos and more details in the previous post:
https://hitechfromlotech.blogspot.co.nz/2017/12/xmsnakerobot-construction-completed.html

-----------------------------
I have done a little speed up of testing by soldering together an adapter cable set to run the snake robot off an external battery or power supply. The internal batteries are model aircraft LiPo types which need careful charging and setup for each working session. It is faster to get into a testing session by simply "plugging it in to the extension leads" (12 V).

XMSnakeRobot - Construction Completed - Testing - I2C issues

Snake Robot structure completed and electronics fitted.
Now into testing and modification.
The good news is that all servos are responding to test commands as planned.
The main challenge is that any test command that runs I2C code is causing the Master Arduino Nano to freeze. Here is a rewording for less-specialist readers: The "I2C" consists of 2 wires running the length of the snake which act as its "spinal cord", enabling 3 x electronic circuit boards to "talk to each other".

Searching .. From Arduion forum thread "I2C with internal pullups"
https://forum.arduino.cc/index.php?topic=369003.0

"Koepel" says:
"If an Arduino is Slave, and it has the power turned off, that will keep the SDA and SCL low via the diodes." 
I am testing parts of the snake robot first before powering it all up so I do indeed have "Arduino Slaves" with power turned off. Good candidate.

Some contributors state that I2C needs "pullup resistors". "Budvar" writes"
"I tested I2C with the internal pullups a time ago. My experience is that it doesn't work. I2C works with the pullup ~10k on short distance. Recommended value is ~5k on most devices so internal pullup is unusable."
Suggested values in the posts include 10K, 4.7K and 2.2K. I have added 6.8K pullups.

One contributor, Nick Gammon, has a detailed article with example code on his own website:
http://www.gammon.com.au/forum/?id=10896
Nick Gammon recommends 4.7K. I read this after soldering 6.8Ks into the snake but I will keep this in mind!

The plan is to work through these possible fixes to try to get I2C to work.
If still no go, then "Plan B" is to turn to "SoftwareSerial" on the master Arduino to run separate Serial conversations with the 2 slaves.

Snake Robot structure with version01 electronics in place.

L to R ribs 3, 4, 5. Rib04 has the highest complexity
because it includes the master microcontroller.

Close up on Rib04 with the "master" Arduino Nano.

Managing the wiring of 20 servos - use of dashes and dots:
Dashes indicate horizontal movement servo, dots for vertical.
Also colour coding. Section Front-Back: orange, white, yellow, green

Rib05, bottom view here, is a battery holder.
Battery mount on the left - regulator and fuse on the right.

Rib05, bottom view, with battery in place

XMSnakeRobot - Construction progress

Photos and notes from 16 Dec 2017

Body structure and actuators are now in place.

Making progress on fitting the electronics and cabling.

I am working to a plan - ref Github:https://github.com/manukautech/XMSnakeRobot
That plan is getting many rewrites as I build.

There is a lot of detail problem solving in building this prototype. Especially fitting in components and wiring in such a way that it is possible to easily dismantle a segment for repairs or modifications. It reminds me of my diy past lives building model aircraft and repairing old cars.

• I found that it is possible to fit battery and regulator on the same rib, rather than on 2 adjacent ribs. That gives a welcome cabling simplification.
• Allowing for cable flexing on movement turns out to be easier than expected. A simple loop path gives enough room to move and flex.
• I needed to change the rib cabling hole position to move cables away from the servo swing arms.
• I needed the equivalent of tiny multi power adapters on each rib to plug in multiple servos and electronic modules. Cutting up a breadboard into micro breadboards with a hacksaw works well.
  
• Hair dryer softens glue. I needed to adjust a servo position. Servo was glued in place with "araldite", a two-part epoxy glue. I read that this would soften at about 80 degrees C so I borrowed my daughter's hair dryer and that worked to release the servo so I could re-glue it.

XMSnakeRobot - Skeleton assembly

10 segments and a head piece. XMSnakeRobot assembly on my workbench. Next to fit batteries and electronics.

XMSnakeRobot - A rat-hunting snake robot

The Youtube Video - success with one segment - I am now building and joining 10 segments:

Why a Snake Robot? For hunting rats! Here in New Zealand we have rats etc, alien to these previously isolated islands, harming our much loved native bird populations including the national icon - the Kiwi. Think of a remote controlled small robot in the world of the rat and that world has mud, undergrowth and broken terrain where a snake form factor is worth trying. And we can get "bio-inspired" and realise that snakes are effective bio rat-hunters so it may be good to learn from them. This is an ambitious aim to build towards step by step with an indoor testbed first. If rat-hunting does not work out then there are plenty of other possibilities like robot circus performer and Youtube stardom. If cats can be stars on Youtube then maybe snake robots can be the next big thing!  

When I started this I thought snake robots were a regular thing in robotics and I would be adding value for rat hunting. As far as I can tell there is a lot of snake talk and not so much snake action. As in only a small number exist as one-off academic projects. This places this project more on the "cutting edge" than I expected which is a little scary-snake but also exciting that this can be something special.  

Part of the "Creative Repurposing of Accessible Technologies" Project at the Manukau Institute of Technology in New Zealand.

Here the Accessible Technologies are:

• Low cost Android SmartPhone or Android SmartWatch for the robot "brain"
• Arduino Nano microcontrollers for the robot "spinal cord"
• Bluetooth HC-05 module as the link between "spinal cord" and "brain"
• SG-90 model aircraft servos - 20 of them. 
• The snake has 10 segments each of which has servos for horizontal and vertical movement.

XMSnakeRobot is an open source project on Github:

https://github.com/manukautech/XMSnakeRobot

The license is "Apache 2.0" - "A permissive license whose main conditions require preservation of copyright and license notices". For anything mission critical or commercial it is best to check the license to be reassured that the license is supportive of what you want to do. Apache 2.0 has a good track record supporting a lot of projects and components which is why I chose it.

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

• Stepper Motors - a well-documented solution capable of precise control but the affordable common 5 volt motor would give us a very slow-moving robot.
• Motors with Hall Sensors to enable precise speed control eg
  http://www.dx.com/p/12v-220rpm-dc-gear-motor-with-hall-encoder-silver-multi-colored-436609#.WeyCYGiCzIU
  I am still searching for details on how to work with this.

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.

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:

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.

https://github.com/manukautech/XMRemoteRobot

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.

https://r2.manukautech.info/


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

https://www.youtube.com/watch?v=aVQCipqSoCs

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:
https://digistump.com/wiki/digispark/tutorials/connecting

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);
  //delay(200);
 
  delayMicroseconds(m);  
  delayMicroseconds(m);
  delayMicroseconds(m);
  delayMicroseconds(m);
  delayMicroseconds(m);
  delayMicroseconds(m);
 
  digitalWrite(0, LOW);    // turn the LED off by making the voltage LOW
  digitalWrite(1, LOW); 
  delay(3000);               // wait for 3 seconds
}

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.

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.

Item	Weight(g)
Change Sun 50mm Ducted Fan	66
Hyperion Battery 3S Lithium Graphene	77
Hobbywing Flyfun 30A ESC Controller	26
Vodafone VFD-300 Mobile Phone	65
2 x Chihaimotor Geared Motor	20
TOTAL	254

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.

The Mocket - Mock Rocket - here's looking at you SpaceX Falcon

The project - experimenting with mobile phones as "robot brain" processors. 

The device challenge - mobile phone as model rocket flight controller, flight recorder, video camera, telemetry.
Oh and let's try landing the rocket like a SpaceX Falcon 9. Like this.

An Educator's approach - "staircase" - with early test vehicles which test parts of what is needed and perform less ambitious flights and ground tests as we work towards this grand aim, learning a lot along the way - which is the real payoff here.

Enter - "The Mocket" or mock rocket.
Idea - it looks like a rocket, but the motor in the tail is an electric "fan-jet". Same position, same thrust direction, similar moveable mount and controls as what a "real" ie not-atmosphere-dependent rocket motor would need. We can get started on phone-sensor-based flight control because "The Mocket" is easier to work with and has less in the way of flying permission issues than the possible later rocket.

The "Change Sun" 50mm ducted fan specs state: "Static Thrust :  Around 510g At 11.1v (25A)"

Question One  - do the core components add up to well under 510g?

Here goes:

Item	Weight(g)
Change Sun 50mm Ducted Fan	66
Hyperion Battery 3S Lithium Graphene	77
Hobbywing Flyfun 30A ESC Controller	26
Vodafone VFD-300 Mobile Phone	75
2 x Chihaimotor Geared Motor	20
TOTAL	264

Assume for a reasonable climbing performance we need a total weight of 400g, this gives a "weight budget" of 134g for structure, wiring, other needs arising.
Challenging but good enough for a go-ahead.

Note - The mobile phone weighs 103g but it is possible to remove its battery (28g) and run it from the 5V "BEC" power supply provided by the ESC = Electronic Speed Controller. That gets the phone down to 75g.

Robotics - LiPo power and keeping it safe

Robotics experiments continuing. I have started by powering "Creative RAT" (Youtube Video Here) with a common 9V battery but it goes flat after only a few minutes of demo. Time for something rechargeable and better. Next up is to try changing to a 7.4 Volt "2S" (2 cell) LiPo battery as used in Radio Controlled model aircraft. These have an excellent power capacity but they also carry a risk of catching fire and melting down if overcharged or undercharged so we need to regard them as "prima donnas" needing much loving care and attention. My first 2 "Wild Scorpion" batteries cost 10 NZ dollars each but they need a support infrastructure!

Storage. In a special fireproof "LiPo bag". I am keeping this bag on a steel shelf by a brick wall.

Safe voltage range. 3.1 to 4.2 V.  Range centre and commonly quoted rating is 3.7 V per cell (7.4 V total - I will quote per cell from now on).

Max voltage when charging is 4.2 V per cell. For LiPo batteries we need to buy a special charger which "balance charges" each cell individually and gives an optimum charging sequence of voltage and current over time.

ISSUE! PROVIDE A CUTOFF
Low-cutoff voltage recommended by "HobbyWing" is 3.15V ^[1].  Others say 3V. The battery is at risk if it falls below that. This is a big issue for us because Quadcopters etc all have "ESC" (Electronic Speed Control) units with cutoffs. We are doing speed control differently so we need to provide the cutoff.

I am starting with a small unit that sounds an alarm at 3V for any cell. ^[2]

 This is a warning beeper rather than a cutout but when I get this I plan to investigate the power supply to the beeper to see if it can power a relay or trigger a MOSFET for cutoff. I am also calculating and sketching possible diy cutoff circuits.

POSSIBLE ALTERNATIVE
One of the aims of this project is to find ways and means that can work well for getting teenagers interested in tech - as well as being do-able in places like School Science Labs and after school workshops. I am guessing that the special care demands of the full-on LiPo are a heavy responsibility "turn off" for these situations.

Point and shoot cameras use efficient rechargeable Lithium batteries, single cell, 3.7 V
They should have less critical care needs because the battery includes an electronic module which includes a cutout. Can these work as our robotics batteries?
[NOTE LATER - Tested 2 such batteries - one is working well, the other "died" under test load. Therefore it looks better to follow common practice for radio controlled model cars and use NiMH batteries.]

------------------------------------------------------

[1]
http://www.hobbywing.com/products/enpdf/Flyfunlow.pdf
The HobbyWing FlyFun ESCs have selectable cutoff options of  2.85V, 3.15V and 3.3V. I plan to follow their "medium" setting of 3.15 V as a good recommendation.

[2]
BW4701 AOK 1-8S Lipo Battery Tester/ Low Voltage Buzzer Alarm
NZ 9 dollars from "HobbyHangar" in Hamilton, NZ.

Robotics - Robot meets Mobile Phone - light can bring them together

Phones have amazing computer power. Let's use phones as Robot brains! But phones do not have arms, legs wheels, wings and other interesting ways of doing robot movement. Here is a clear, obvious way to get started on fixing that. Programming light patches on the screen.

Suggestion: That this "light patch" (aka "opto coupler") approach can help with STEM education. Maybe a setup where students can see the workings of the building blocks can help get them engaged?

Next step - a robot vehicle, the "Creative RAT".

Here a confession that this "Creative RAT" is not very creative. It repeats a 16 second sequence of forward, turning and reversing movements. That does sometimes make it appear to be relating to its enviroment - see the end of the video - but those are just coincidences, or the way that running through the cycle of movement will hit on something that works for the chair or table leg that it is stuck on. The name comes from "Creative Repurposing of Accessible Technologies".

Light patches are looking promising as an interface, They are easy to program compared to other interfaces. Control seems to be more precise than expected. This is working well on a low cost cellphone. Testing is good - we can get a lot of testing done with the phone alone without the need to run the robot or even have it handy. We can watch the light patches to see if the expected light-ups happen.

Programming note - follow-up to the posts here about which platform to use. I find that Xamarin has improved a lot with the release of "Microsoft Visual Studio 2017 Community". The Visual Studio install seems to include all components without the need for other supporting installs. We now have a primitive visual designer. I found this was good enough to prototype my UI, then looking at the markup code helped me get into fine tuning. Compile and run speed is a big improvement.

Electric Toothbrush Aircraft - Fly Toothbrush, Fly!

It flies!

First Flights - including aircraft point of view from onboard micro video camera:

Youtube Playlist - 5 videos with subtitles so click the "CC" control.
https://www.youtube.com/playlist?list=PLRW7rpX_t2THfuOh6X6mS-8l0KPWXMpR4

Part 1 - The Motor
https://www.youtube.com/watch?v=G-Umg4CxYdE
A local supermarket has started selling low cost electric toothbrushes that are noisy and powerful so of course that sets me thinking - can this thing fly?

Part 2 - The Propeller
https://www.youtube.com/watch?v=T_Bwqh9WUT0
Aiming here to design a low cost kit - the motor unit, switches, propeller (and optional micro video camera) can be re-used for each group of learners. The aircraft and some accessories probably need to be new for each group project at a cost of about USD 10

Part 3 - The Balancing Act
https://www.youtube.com/watch?v=rkIVqzPQj8U
We test that the aircraft flies in its original state as a "chuck glider".
Then find the centre of gravity by balancing the aircraft with one finger under each wing. Mark that because we need it to balance in the same place after we add the motor.
The first attempt to fit a motor is "super nose heavy". Try again mounting low so the battery can fit under the wing. This time it balances. Then some work with rubber bands and a cut piece of pencil as a peg to hold it in place.

Uncontrolled free flight is a bad idea when this can go "wild" for 4 minutes of running time. Possible simple controls are a timer to give a short running time, or some kind of tether like "control line" or "around the pole". Or both timer and tether. We go here for the "around the pole" tether as the simplest method. We use monofilament fishing line. Size 0.45mm has worked here. We tie the end to the motor rear mount and line it up with a wire loop taped to the wingtip. The pole bearing is a cut piece of garden hose joiner spinning on an 8mm bolt.

Part 4 - Fly Toothbrush, Fly!
https://www.youtube.com/watch?v=u2rxgNkOoj8&t=19s
If flies! First flight gets 3 times around the pole. Flight02 does 4 circuits and we have a "PlaneCam" operating.

Part 5 - Endurance
https://www.youtube.com/watch?v=DTUAlqW0wQs
Flight 3 is 3rd time lucky with 3 minutes of flight. Less wind seems to make a big difference. With maker discussion and commentary. Ideas to get better include (1) reduce weight by removing the micro video camera .. (2) experiment with a smaller power unit and a smaller aircraft because a scaled down version could work well indoors and learner workshops will need that option.

How can we program Mobile Phones etc in a learner-friendly way? - Part 2

New Year's Day 2017.
Back home with all my computers for the last 3 days. Continuing the search for a learner friendly way to program those phones. Finding some (mostly) good frameworks and methods.

System: "Adobe PhoneGap" - Apache Cordova with some good value added

In Part 1, I was critical of Apache Cordova. On visiting the "PhoneGap" site: http://phonegap.com/
I find that I am not alone with these concerns. And PhoneGap offers some answers.

"PhoneGap Build takes the pain out of compiling PhoneGap apps. Get app-store ready apps without the headache of maintaining native SDKs. Our PhoneGap Build service does the work for you by compiling in the cloud."

PhoneGap have downloads for:

1. "Install our desktop app" - This will create the starter files for an app. It will also test run in a browser acting as very simple emulator. I presume it also runs the "cloud build" process although I have not tested that. 
2. "Install our mobile app" - This phone app can copy the files we are working on and run them directly from the HTML and JavaScript source as an interpreter with no need for a compile process.

"Desktop App" was a straightforward install.

"Install our mobile app" took longer. The version in the "Google Play" store would not install. There was an error message that my phone was not supported. Google search on that led to the GitHub site with developer notes that this often happens and I could download directly from GitHub.
https://github.com/phonegap/phonegap-app-developer/issues/408
That download did install OK.

It took me a long time to work out the relationship between the "Mobile App" and the development computer "Desktop App". Not the usual USB cable relationship. The "Desktop App" runs its own mini webserver for testing. The Desktop App also creates a zip file of the current project which the "Mobile App" needs to download from the Desktop App mini website. It then unzips this as a set of temporary files and feeds them into its mobile browser component with additional Cordova functions available. This means setting up the USB cable as a mini network between the 2 machines.
I found this as a switch-on setting in:
 "Settings" -- "Wireless & networks" -- "More" -- "Tethering & portable hotspot" -- "USB tethering"

The "Desktop App" (also for laptops!) does not provide any kind of coding editor. I used "Microsoft Visual Studio Community Edition".

Compared to the base Cordova, PhoneGap does provide an effective fast-to-start test run on the Phone. This test run is marginal as a practical run in the field like in a moving car. Because to run an app Phone-Alone we would need to start the run with the USB cable connected, then disconnect the cable and do the test run. The test app seems to disappear from the Phone at the end of the test run.

The "cloud compile" reads as an excellent idea. I have not tested it yet.

Using the checklist from Part 1

1. Free or low-cost resources for students and teachers?
   YES - with some rules around free use of  the compiling service which should be OK for most educators and students,
     
2. Exercising widely relevant skills? - I would prefer based on HTML5, CSS and JavaScript.
   YES - HTML5, CSS and JavaScript.
      
3. Works across a range of device systems, with "Android" as the priority target?
   YES - Targets Android, Windows Phone and iOS (Apple iPhones, iPads etc).
     
4. Works in a straightforward manner following straightforward instructions?
   PARTLY - better than base Cordova
    
5. Works smoothly and quickly using the kinds of computers students have access to?
   PARTLY - better than base Cordova

System: Crosswalk by Intel

Looks good reading about it but I was not able to get it to work.
I think there are 2 variations of this. The newer version is a claimed improvement to Cordova mainly by replacing the standard Phone browser component with a better "Crosswalk" component. I was more interested in the older version where "Crosswalk" is an independent system, similar to Cordova but more straightforward. I tried to install on 2 machines. Both gave me error messages that I did not have the Android Softward Development Kit available. But other frameworks I am testing eg Android Studio have previously installed that.

System: "ScriptIt" by Rob Bowman
appears in the Play Store as "Android JavasScript Framework" by Rob Bowman

Home website is https://scriptit-app.com/

This is a very well packaged and documented JavaScript interpreter and a strong candidate for leading package. Rob Bowman has used a Mozilla component to run JavaScript code and given it a well thought out Device API some of which I understand he has written in Java to simplify interfacing with the system. "ScriptIt" includes a capable code editor. I quote from my Part 1 article: "Bring back the educational glory days of the "Sinclair ZX81" and the "Commodore Pet". Well this can! We can edit JavaScript files on the Android Phone or Device. We can also copy scripts to a desktop or laptop and edit with tools like Microsoft Visual Studio.
User Interfaces are achieved by calling to the "native" Java methods so there is no HTML or any other markup language. That could be a challenging learning curve for beginners. Rob Bowman has worked on getting around this with example code examples, snippets and UI starter kits.

Running "ScriptIt" through the checklist - and I can for the first time include the "would be nice" extras of point 6 and 7.

1. Free or low-cost resources for students and teachers.
   YES
      
2. Exercising widely relevant skills - I would prefer based on HTML5, CSS and JavaScript.
   YES - JavaScript with some Java-like coding because of interfacing with a Java system.
     
3. Works across a range of device systems, with "Android" as the priority target.
   ANDROID ONLY
     
4. Works in a straightforward manner following straightforward instructions.
   YES - but - with a learner warning that UI all by code may be challenging.
     
5. Works smoothly and quickly using the kinds of computers students have access to.
   YES - can work with device only. App download is approx 2 MB which is up to 700 times smaller than some of the other frameworks.
     
6. Be able to "interpret" scripting code so I can experiment with an artificial intelligence idea I have of machine learning happening by the machine rewriting and adding to its own programming code.
   MAYBE - Normally a ScriptIt "App" is one text file of JavaScript code but it does have a capability to load other files as "child" processes.
     
7. Learners can program phones by typing code into the phone. Bring back the educational glory days of the "Sinclair ZX81" and the "Commodore Pet".
   YES

System: Direct use of Google Chrome
The system that is not an added framework at all but is simply about using the browser that is already on the phone with HTML, CSS and JavaScript. There are some helper Apps that may be useful.

During my extensive Google searches and online reading, I began  to get some hints that the Google Chrome browser already on my phone might be more capable of phone interfacing than I had realised. So I started an experiment in placing a website in a folder on the phone and running it directly from there with Google Chrome.

The simplest approach is to type a file address into the browser.
eg Under "Internal Storage" aka "Phone" I have a folder "devc" with subfolders for each website-app.

I start app "test09" with this URL address:
file://sdcard/devc/test06js/index.html



Note - strange that the internal storage has an "address" of "sdcard" in this phone. The phone also has an SD-Card but that file address looks quite different being a code that looks like a serial number.

I have also downloaded a Play Store App "Tiny Web Server" which has a file browser to find the web app folder, The Google Chrome address then becomes:
http://127.0.0.1:8080



This has advantages because Chrome recognises it as a "full" internet technology website. For example Chrome can remember permissions we have granted previously.

Another useful optional extra is a Play Store App "DroidEdit" which enables code editing on the phone.

By default, web browsers like Google Chrome are designed to give low trust to website code because of its origins on distant machines. My tests so far show that code originating from on the phone by both methods seems to be more trusted with a default setting of asking the user for permission via an on screen prompt. It does appear to be possible to "train" the "localhost" address http://127.0.0.1:8080 to remember permissions by pointing it to a test app that requests lots of permissions.

More testing to do but Google Chrome, with "Tiny Web Server" and "DroidEdit" is looking like a good candidate especially for beginner learners. We can create "Apps" as websites which almost exactly follow standard website coding. Coding for Phone Features involves only some new keywords for use in the same kind of JavaScript coding. Other systems will be needed when we get more ambitious eg publishing to other people. Now for that checklist:

1. Free or low-cost resources for students and teachers.
   YES - but note that helper apps like "Tiny Web Server" by Leonardo Javier Russo  and "DroidEdit" by Andre Restivo have ad displays in their free versions. The ad-free "pro" versions are $1.34 and $3.48
      
2. Exercising widely relevant skills - I would prefer based on HTML5, CSS and JavaScript.
   YES - mainstream standard website coding: HTML5, CSS and JavaScript.
     
3. Works across a range of device systems, with "Android" as the priority target.
   YES - uses standard web browser, preferably Google Chrome, therefore very wide reach. Both helper apps claim to support Android down to 2.1 (not tested yet) which would be good for teaching and learning with old phones that are very low cost or get donated to schools. I want to launch flight data recording apps in model aircraft and model rockets so it appeals to me to use low value donated phones. I note too that phones by fashion are getting larger and heavier, even the cheapest ones, so an old phone of small size also appeals for flying machine experiments.
     
4. Works in a straightforward manner following straightforward instructions.
   YES - standard website coding with some configuration work needed to enable phone interaction like: location; storage; camera; microphone
     
5. Works smoothly and quickly using the kinds of computers students have access to.
   YES - Simple creating and editing is possible on the phone. Websites can be created, and partly tested on laptops/desktops using editors like Microsoft Visual Studio Community then copy the files to the phone.
     
6. Be able to "interpret" scripting code so I can experiment with an artificial intelligence idea I have of machine learning happening by the machine rewriting and adding to its own programming code.
   MAYBE - Not tested yet. Will depend on how tests go with the file system API.
     
7. Learners can program phones by typing code into the phone. Bring back the educational glory days of the "Sinclair ZX81" and the "Commodore Pet".
   YES

General Phone Notes
Some general discoveries and observations about Android phones, and maybe phones in general.

SDCARD - "Internal" or "External"?
Based on my experience with adding memory card storage, when given this option I went for "External". This is the setting where the card holds optional extra data and can be removed and read on another machine. The alternative "Internal" is where the card adds to the Phone/Device becoming part of the Phone and should not be removed.
I am now changing my mind and recommending "Internal". My reasons are:

• Some apps cannot read the "External" card at all or can only read it with configuration changes which can cause problems.
• The "External" card is of limited use when connected via a USB drive. I find I can cut, copy, paste, delete and rename files but I cannot work on files or sets of files in place as I could with a USB drive. I wanted to create and edit websites on the "External" card while the Phone was plugged into the computer via a USB cable. Then config and run them on the Phone. Microsoft Visual Studio Community and other desktop software could not work this way. Therefore an expected advantage of "External" does not happen.

Android Phones and Security - care with where Apps and Code come from.

Here is an instructive story from Rob Bowman, creator of the fine "ScriptIt". Share this with your learners - I will.

robwbowman 9:06 pm on December 15, 2016  

Use Trusted-App-Stores

Viruses and malware are a real problem. Using trusted-app-stores like Google Play and Amazon Appstore reduces exposure to these threats by the app-store aggressively testing, reviewing and scanning for malicious apps.

What about the other app-stores?

Recently, I found ScriptIt on untrusted-app-stores. Since I didn’t release to these app-stores, it means someone downloaded from a trusted-app-store to an emulator/device, extracted the ScriptIt-APK and uploaded to their site.

Being curious, I downloaded this untrusted-ScriptIt-APK inside a sand-boxed environment and determined the app had a rootkit that obtains control over the Android operating system, collects vital information, and is very hard to remove. Next, I downloaded other well-known Android apps and they each had the same rootkit embedded inside them.

The important lesson is always use a trusted-app-store.

Ref:  https://scriptit-app.com/2016/12/15/use-trusted-app-stores/

Rob Bowman supplies "ScriptIt" for free on the official Play Store so there is no need to download illegal damaged copies from anywhere else.

This is Part 2. You can read Part 1 at:
http://hitechfromlotech.blogspot.co.nz/2016/12/how-can-we-program-mobile-phones-etc-in.html