Raspberry Pi and Rasbian OS disappointing result. TODO try Windows 10 IOT.

My common robotics architecture is:
Android Smartphone in the role of "Robot Brain" communicating via Bluetooth to Arduino MicroControllers in the role of "Spinal Cord".
I have done some experimentation with a "Raspberry Pi Zero" as an alternative "Robot Brain" and I revisited that today. I have setup and run the "Pi" for remote-control with VNC using "Pi Bakery":
https://www.pibakery.org/
which I have found to be excellent value. "Pi Bakery" installs "Rasbian" which is "Linux Debian" customised for "Pi". "Pi Bakery" includes additional customisation to get Pi to begin running by remote-control over WiFi or over a USB cable. No screen or keyboard required - Pi borrows your computer or laptop screen, mouse and keyboard.

Today started well. I ran my project "XMRemoteMonitor" which is a wildlife or security camera web app.
https://github.com/manukautech/XMRemoteMonitor
The functionality is all in the web app so no installation needed. I only needed to visit my  website with the built in "Chromium" browser. This does need to access the device camera. I had an expensive Pi special camera plugged in but the Web App could not find that. Then I plugged in an old general purpose Microsoft webcam from one of my boxes of old leftover tech and that worked including automatic plug-and-play recognition. All good so far, acting like any other device. The Rasbian desktop even gives me a Windows-like experience.

But then the Pi only took 27 webcam photos over about 5 min before completely freezing up. The screen was still visible and connecting via VNC but all controls were frozen. During that 5min I did get readings of 0.29 and 0.30 Amp for the current drain. This is similar to smartphone current draw when they run the same app. As a mostly Windows practitioner I have Linux friends teasing me about Windows freezing. Well! It appears Linux can do that too!

This gives me an idea for my next Pi trial. Install "Windows 10 IOT" which is a lightweight Windows 10 for small devices like the Raspberry Pi. Then run the same web app - will it go better?

Results in the web app:

Setup. The Raspberry Pi Zero is the small green circuit board sitting on a white powerbank.
Pi has 2 x micro USB ports. The left USB is fully functional and I have plugged the webcam into it with an adapter. The right USB is for power supply only.

Journey of the Rocket 03 - Water and Electronics do mix!

Link to full article on Facebook:
https://www.facebook.com/groups/nzrocketry/permalink/10161300046625696/

I am getting more and more interested in doing interesting things with low power rockets. It is education and robotics that led me to a rocket interest. My rocket-for-education design that started with a rocket motor of "E" power rating is now reducing and I am now designing for "B" power. The aims being:

• to be able to launch from school grounds 
• to take sensor readings
• to do all-electric recovery.

I think even small rockets need to detect apogee with an altimeter to control recovery and the electronics involved are now small enough and low cost enough to work as part of a student project. The video shows - shock! horror! - a water rocket for prototype testing of an altimeter circuit. That does achieve proof of concept although I am having challenges with lightweight battery versus relatively power-hungry bluetooth module.

Journey of the Rocket 02 - Catapault(?!)

Link to article and video on Facebook:
https://www.facebook.com/groups/nzrocketry/permalink/10161245144325696/

Trying out some rocket design ideas eg air brakes by launching a test body with a catapault to get a close-up look at apogee behaviour. The air brakes do not deploy but I get some other good learning value. The tail fins seem to be remarkably effective at low speeds as in too effective. They are pointing the body nose down very soon after apogee which keeps the air flow going past the body from nose to rear which keeps the air brakes closed. I was hoping for some random airflow to catch the air brakes and help them open.

Journey of the Rocket 01

Rockets! These have been one small activity in the "HiTechFromLoTech" project, the idea being to use our by now sweet combo of smartphone-bluetooth-arduino as rocket and model aircraft flight recorders possibly leading to flight control. 2 students picked this up as their project at the end of 2018 and they have done excellent work with it, to the point that "Rockets" may take over as the flagship or number one activity here.

Sun 11 Nov launch day with NZ Rocketry at their launch field on a farm was excellent value for my students and me. Thanks to everyone for making us welcome. Special thanks to Alex for his help and advice and for flying our smart-phone-as-flight-recorder experiment, Thanks also to Jim Hefkey and Tristan O'Hanlon of APSS for their help and encouragement. Some findings: The lowest cost smart phone, Vodafone VFD-300, ($39 on special) did take video and record data. Data recording rate was about 15 samples per second. Our altimeter graph is close to Alex's TeleMega result. GPS results are approximate and the GPS biggest achievement is to place us on the farm. The most accurate GPS result is for walking down the track with the recovered rocket. The smart phone is working well after its flight experience. Jasmin gets a programming hero award. The day before she upgraded the user interface and data recording stopped working. On Sunday, Clinton drove while Jasmin did extreme phone programming. She got data recording up and running again minutes before the launch. Graphs are by our data analysis student Li who has been digging up her high school physics knowledge to analyse this. Our next experiment will be to try using GSM 3G cellphone data networking to send data to Earth while the rocket is in flight.

Alex loading our student instrument package into his rocket

Student instrument package in place

Data collection - smartphone records data into its SQL-Lite database

Data Analysis done post-flight - "Journey of the Rocket" 

More at:
https://www.facebook.com/groups/nzrocketry/permalink/10160980281785696/

XMRemoteRobot - SignalR - nice messaging but watch out for the size limit

Early successes with SignalR for Internet communications got us thinking, "let's use SignalR for everything!". Sending images from the robot camera being first on our TODO list. As in see through the robot's eyes. We attempted sending images as "base64" strings. We can share with you that SignalR does not handle big strings in one message. When we tried this we had no error messages and apparently almost-working results like the first image received as a small black image. That looked promising enough to keep trying until we thought of  testing with smaller message sizes and our broken communications started working.

Time for a Google search. "signalr maximum text length" which found
"There's no maximum message size but we recommend < 32K per message" on the Github home site. ref: https://github.com/SignalR/SignalR/issues/1205

That got us trialling different sizes of messages on XMRemoteRobot with the finding that our maximum reliable message string length is 32700 characters.

We process the still images from our robots into 'base64' encoded strings of about 640K in length so that is not going to work as a single chunk. Next steps in this development:

• For stills to store on a server for a security camera application we will roll back to HTTPS and AJAX.
• For video streaming the most promising technology from our Internet readings is "WebRTC" which is direct peer-to-peer communication with the need for an initial protocol setup step which requires a server. Various sources are reporting that SignalR is good value for that initial setup step. Ref:
  https://www.skylinetechnologies.com/Blog/Skyline-Blog/February-2013/Peer-to-Peer-Media-Streaming-with-WebRTC-and-Signa

A possible alternative. "Ricardo" writes about achieving video streaming without audio over SignalR:
https://weblogs.asp.net/ricardoperes/video-streaming-with-asp-net-signalr-and-html5

Big Update! XMRemoteRobot 2.0 speeds up with SignalR

Big advances in our open source server app for remote control and/or remote monitoring over the Public Internet.

XMRemoteRobot 2.0 is a major rewrite replacing "http long polling" with "signalr" giving faster, more direct communication. The latency (delay or lag time) is down to 10ms on local networks and 70ms over a 4000 km test. The new app replaces the database with in-memory objects. This means that the download is ready to run immediately in Visual Studio 2017. This also makes for easier  deployment..

Downloads and more details at: https://github.com/manukautech/XMRemoteRobot

Live Demo - test drive this app at:
https://xmrrnz.manukautech.info - Server located in Auckland, NZ.
https://xmrrae.azurewebsites.net - Server located in Azure "Australia East".
https://xmrrwu.azurewebsites.net - Server located in Azure "West US".
You can see the (low) latency at different distances.

For pages "Test01" and "Test02", commands travel from the left side of the page, to the server, then back to the robot code separated into an iframe on the right side of the page. Or to your smartphone-acting-as-robot when you navigate that to pages "Robot01" or "Robot02". Therefore multiply the distance to the server x 2 for the remote control distance.

"signalr" is a Microsoft-sponsored open source project which implements "WebSockets".

Snake Robot moves faster - sideways

Snake Robot - moving faster. I would say "baby steps" meaning improvements in small steps except that snakes do not step, they have "gaits", so this is progressing by "baby gaits".

System voltage is up from 5V to 6V to get more servo torque. Achieved by replacing step-down "buck" voltage regulators with "buck-boost" regulators which have both step up and step down capability. This means that they can maintain 6V over the range of 2-cell lithium battery supply voltage: starting at 8.4V and dropping in use as they drain to the lowest operational limit of 6.4V.

More important: A new programming approach for gaits that makes development easier and the code more self documenting. With this comes the programming of new gaits that perform well along my workbench but not so well across the floor. Except for "rectilinear reverse inchworm double wave ripple" which does move faster, but sideways, which is a surprise, very different to the programming good intentions. Great movement, now we only need to sort out the lesser issue of going where we command.

XMSnakeRobot is an open source project (Apache License) with programming code and designs published on "Github".
https://github.com/manukautech/XMSnakeRobot

Gait coding:
https://github.com/manukautech/XMSnakeRobot/tree/master/CodeBrainAndroidJavaScriptDroidScript/XMSnakeV06

Coding in JavaScript for the best gait so far, the "rectilinear reverse inchworm double wave ripple", is pasted below.
Gait "functions" now consist of data in arrays specifying cycles of servo angles. These arrays are interpreted by common code in the main program.

function Gait02() {

    var vert = [
        [-30,  20,  20, -20,   0, -20,  20,  20, -20,   0],
        [-10, -20,  20,  20, -20,   0, -20,  20,  20, -22],
        [-10,   0, -20,  20,  20, -20,   0, -20,  20,  15],
        [-10,   0,   0, -20,  20,  20, -20,   0, -20,  40],
        [-30,  40, -20,   0, -20,  20,  20, -20,   0,   0]
    ];

    var horiz = [
        [  0,   0,   0,   0,   0,   0,   0,   0,   0,   0],
        [  0,   0,   0,   0,   0,   0,   0,   0,   0,   0],
        [  0,   0,   0,   0,   0,   0,   0,   0,   0,   0],
        [  0,   0,   0,   0,   0,   0,   0,   0,   0,   0],
        [  0,   0,   0,   0,   0,   0,   0,   0,   0,   0]
    ];

    return [vert, horiz];
}