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.


ItemWeight(g)
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
TOTAL254

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.


Wednesday, July 19, 2017

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:

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


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.



Tuesday, July 11, 2017

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.







Saturday, June 24, 2017

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.

Saturday, April 1, 2017

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.

Sunday, January 1, 2017

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