Internet and sheep at the same time

[shardros]

The memes are True. A large part of independent problem solving in the 21st centry especially with programming is being able to google effectively. The current system design stops this self lead exploration.

It also puts more resistance to individuals contacting us through the forum.

Therefore the users machine should be able to remain connected to the internet.

The following properties of our system: are good (though maybe some are obsolete now that we ship laptops?)

• Can work in the locked down enviroment of a school. It should not require any schools IT department to do anything to support the system
• Can work on any machine. Students have a wide range of devices with different archetectures and different operating systems, from chrome OS to windows.
• Wireless. Being able to stay at the laptop whilst debugging makes the experience so much better.
• Can send logs and images back.
• Requires no software to be installed on the users machine
• Works with hardware which we can expect to be in every laptop
• Does not expose the unpatched pi to the internet in a way where we have to worry about security updates
• Can support multiple users reading (but not writing) concurrently

Would be nice to haves in a new system:

• The users machine can use the web through a browser at the sametime
• Software updates to the brain with minimal user interaction.

This thread is to hash out ideas for potential solutions

[casheww]

Very unbaked thought - if users could connect to the brainbox via bluetooth then they'd still be able to connect to the internet via a normal wifi network. Obvious downsides being that not all laptops have bluetooth capabilities and we wouldn't be able to serve the docs and editor as webpages in the way we do now...

[shardros]

There is a bluetooth API for webpages to connect to browsers so it is conceivable to host sheep on the website and then connect through bluetooth that way which would still lead to the same intergrated experience: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API

However the API for the last 7 years has been marked as "experimental" and only works on chromium based browsers which is like 90% of all browsers. There are revisions made to the specification on about a 1 month cadance at the moment. Maybe this is too experimental.

Alternative would be electron.

[shardros]

Bluetooth dongles for laptops are also very inexpensive so I don't think it is a blocker if some laptops don't have them.

Personally I am leaning towards repackaging sheep as an electron desktop app which works over bluetooth. This way you don't need internet to work. Downside is that it will require custom software to be run on user machines which is okay if we are going to provide them with laptops.

Not sure if we would want to have a legacy mode where shepherd comes up either as a WAP or with bluetooth.

[fenjalien]

I started rewriting shepherd/sheep a few times a while ago using different technologies like python with fast-api or rust. These are the repos (they're private but message me and I'll give access)
https://github.com/fenjalien/shepherd-fast
https://github.com/fenjalien/shepherd-rs
https://github.com/fenjalien/robot-rs
https://github.com/fenjalien/brainbox
They all had varying success.

I started them as the general brainbox structure was confusing, old, and not that well built. Although it worked fine it can definitely be simplified and improved.

I'll hopefully have some time over the summer to take another look and help out.

[shardros]

oooh nice, would you mind giving a summary of what each of these 4 are?

[fenjalien]

Sure
https://github.com/fenjalien/shepherd-fast - A proof of concept to use the python package Fast-API(https://fastapi.tiangolo.com/) instead of flask. Fast-API arguably better on many parts than flask and it feels all warm and nice to me. Looking back at the code it can only start, stop usercode in a directory and return the output. I'm pretty sure I had it at a point where you could upload it but I guess I didn't push :/

https://github.com/fenjalien/shepherd-rs - An implementation of sherpherd but in rust using Actix(https://actix.rs/). I'm pretty sure the API to start, stop, upload, delete and output are working. I didn't touch anything todo with the text editor.

https://github.com/fenjalien/robot-rs - An implementation of robot but in rust using Rppal(https://github.com/golemparts/rppal). Rppal just gives an interface to gpio and etc (like wiringpi and stuff). The project is setup as a library and cross compiles to a python library using PyO3(https://github.com/PyO3/pyo3). I think i got this working and it looked at acted pretty much the same to the robot library. I even got apriltags working through it (apart from the fiddly camera settings, i would just get confused).

https://github.com/fenjalien/brainbox - I'm pretty sure this was just a dump of the above two repos along with additional stuff i was testing out. Or it was an attempt at creating a proper structure and finding a way to fit everything together.(i don't remember how far i got)

A quick lessons learnt (from terrible memory)/points i would like to make

• Writing stuff in rust is slightly more painful and confusing but it will tell you very nicely where and when you go wrong. In comparison, we've had python in the past silently crash and kept its mouth shut tight.
• You need to cross compile rust to the rpi, which at the time was pretty difficult to do on windows, linux makes it far easier. This may have changed in the last 2 years or so.
• Shepherd would be best in python and transfer over to Fast-Api than contiue with flask. Writing it in rust is a little too much work as you have to worry about mutex types and everything (again this may have changed in the past 2 years but i doubt it).
• Robot lib would be better in rust. A systems level language just generally suits it intstead of a higher level. Also rppal and other hardware abstraction crates are really nicely written. Also also compiling to python somewhat obfuscates the code so we can stop anyone poking around and breaking stuff.
• I agree python is easier than rust but rust is easier and nicer to work with than C or C++
• Shepherd shouldn't take direct control over the robot (it only does this to reset everything but even so thats baad). Instead I propose that three processes should be running on the brainbox (I think i started on this in the brainbox repo).
  1. A hardware controller with some kind of input system for external processes to control it. Such as a tcp or udp server or some other kind of messaging system. I remember looking into zeromq(https://zeromq.org/) and the likes as theres a rust implementation. Acts as a single source of truth of the robots state. This could auto-reset when a connection to the usercode drops?
  2. Shepherd as it normally does. It's only interaction with the controller should be for status checks and possibly to reset it. Shepherd could also have a pass through API allowing remote control?
  3. Usercode with a simplified robot lib that just connects to the controller. All gets and sets just callback to the controller.

[fenjalien]

I realise that this wasn't the best place to dump info woops.

We could just provide wifi dongles, pretty sure that allows connecting to two networks at the same time.

[shardros]

I hadn't considered two wifi networks, my only concern would be DNS.

I don't know if browsers would then understand how to navigate to http://robot.go if we had two wifi networks? Currently the brain says all URL's point to it. idk how that would work with DNS with two networks or how to do that properly.

If it could be made to work maybe that would be the cleanest solution.

[shardros]

Thank you for all of the points about the various repos. I do quite like the idea of shepherd-fast. We need unit tests for shepherd but that might just be easiest with a re-write. Its quite hard to work out what you are trying to write unit tests for at the moment. It would be nice if some how we could automagically generate mock-shepherd from shepherd so that it was always upto date not sure how best to do that.

mock-shepherd is only needed because shepherd only runs on a pi not run on x86 which sheep's debug build only runs on.

Shepherd shouldn't take direct control over the robot (it only does this to reset everything but even so thats baad).

I very much agree with you that this is bad. It feels to me like implement/maintain a whole seperate module with a messaging system is alot of work. Do you think the pay off is worth it?

Reset is hacky but its one function. Maybe a simplier way would be to have shepherd instanciate robot and then you just do:

import robot as R

R.motors[1] = 100
R.see()

The robot object lives within shepherd and is the hardware interface. The robot lib just exposes the shepherd.robot namespace. Then having a reset call on the robot object which is persistant with shepherd isn't such a bad thing. Its just the robot API which is our "HAL". No messaging required.

It even makes the usercode simplier as there is no R = robot.robot() which is a nothing line which nobody understands anyway.

Downside is we would need to be very careful to clear all the state of the robot object between rounds.

Not sure how to do wait for start, at the moment it is possible though I've only ever seen one team ever do this to init stuff with the robot before running robot code. I do think being able to pre-init is essential as a team might want to set servos to some position before start or all kinds of other hw config so their robot fits in the box.

Maybe I don't know enough rust but I'm not 100% sold on robot-rs having the robot lib in the same language as the usercode and not compiling across means that people can and have reached into the robot lib to do all kinds of fun stuff. @William-Woodard when he was competing grabbed the frame from R.see() before it had been processed, makes it harder to work out what it is going to be mangled as if it is cross-compiled.

I do really like shepherd-fast though, shepherd-rs might be valuable if we ever do a bare-metal brain though I'm not convinced that is useful atm.

[shardros]

This would also persistantly let us show stuff like the battery charge in the sheep UI not just when the robot was run.

[WillMunns]

There are plenty of examples of tethering the PI over Bluetooth and then sharing the network over bluetooth.

I'm assuming that the reverse is possible, that the PI can act as a bluetooth router routing to WiFi. If so then we have two options.

1. The laptop could access the PI over bluetooth and the wifi over, errm wifi. You would need to ensure that the PI didn't clash with the IP of the wifi. That probably isn't difficult as nobody uses 172.16.0.0/12 so we could easily pick a 8 bit block without clashing.
   The problem would be that robot.go would have trouble routing. I think the default gateway would probably end up being the last connection made, so if the PI offered DNS it might kill access to the internet as nothing would get the correct address, and conversely there are a number of internet providers who hijack DNS so they can inject ads or other "helpful" suggestions. If we didn't offer DNS ourselves then we could probably get away with just using an IP address, but its not very nice UX.
   Incidentally ISP DNS hijacking poisons robot.go, and some browsers also refuse robot.go as it isn't a TLD and try to be helpful by turning it into a google/bing search. We should probably instead be using mDNS and robot.local. If we are lucky this will cure everything and it will "just work (TM)". We could also continue to offer WiFi connectivity in parallel

2. We could (and this makes me slightly sick, but it would be a good solution for the competition itself) allow connections to the robot by Bluetooth tethering only, and then use the brain to forward to WiFi credentials it knows. I.e. at the competition it would connect automatically to HRFSC guest and provide DNS forwarding so teams wouldn't need to connect to the WiFi.

Note that everything said above including issues also applies to solutions with multiple wifi: solution 1 would have two wifi cards in the PC, solution 2 would have two in the brain

[shardros]

There are plenty of examples of tethering the PI over Bluetooth and then sharing the network over bluetooth.

I did not know this. This would be far better than anything proposed above (assuming the thinkpads we have support bluetooth).

I think option 1. Providing everyone with the WiFi key at the competition is a "low-tech" but reliable way of getting everyone simple, un-complicated internet. Option 2 sounds like something which will break on competition day in some magic way but we will only find out about it breaking then. Maybe taking everyones ability to write code which is worse than arena USBs not working.

[WillMunns]

https://elinux.org/images/1/15/ELC_NA_2019_PPT_CreatingBT_PAN_RNDIS_router_using_OpenWrt_20190814r1.pdf talks about setting up a PAN

[WillMunns]

https://elinux.org/Bluetooth_Network

A PAN network is limited to 7 clients and provides substantially less bandwidth (~700Kbit/s) than other WiFi networks.

[shardros]

Sheep is about 4.5MB at the moment but that can proabally be brought down to 3MB without too much pain. We could then cache the whole of sheep in the browser and so subsequent loads would not be anywhere near as bad.

The first load would be a bit painful at 30 seconds but after that fine. The rest is a 600x400px jpg and some text so 700Kbit/s should be fine for that.

[shardros]

Blockly and the text highlighting "monaco" is most of it, see diagram aranged by size

[shardros]

I guess we would need to test if it can keep 700kbit/s over a 6m arena with people moving around. 700kbit/s is fine but I don't think we want to go much lower.

[WillMunns]

I tried the bluetooth on the PI to a Switchbot and it had greater range than the house Wifi, albeit at the very low datarates used by switchbot.

For dev work nobody is really that far away from their robots, especially when loading the page for the first time.

For the competition, the arena wouldn't be run over BLE it would still run over wifi. We should keep the wifi as an option because its far easier for people to set it up. As long as the Bluetooth is setting up PAN rather than using something "Bluetooth specific" then everything above layer 1 will be untouched and work with either stack.