>That's a broad societal topic, and one I'm neither qualified nor enthusiastic about. I absolutely loathe public transportation, having had to actually use it frequently in urban America. It's both dangerous (blacks), and a practical nuisance.
Mostly I do agree with you. I generally avoid using it when I can, however in euro it's at least tolerable. In the usa I remember it being kinda shit.
>My apologies Anon. LOL I definitely didn't succeed at being concise. :^)
Hehe, you ain't the only one ;)
>Now despite thinking that real autonomous cars are stupid, the STUDY of autonomous navigation is extremely useful. Specifically at a scale that you can install GPS modules and read AR markets (QR codes) to guide a machine along a planetary surface.
Haven't considered it on a global scale, but I imagine that would be massively useful to mankind even today. Oh inter-planetary travel, when will you come...
>Sometimes I even implement simple logic using discrete AND/OR/NAND/NOR gates and transistors if a microcontroller isn't necessary.
I really like that line of thinking. Having cheap-as-dirt MCUs have spoiled engineers and hobbyists alike (myself included sometimes).
>Our road network is really cramped and badly designed.
Very good points. It's too common for techies and marketing to have wishful thinking, while forgetting that infrastructure is a massive cost (that not even a big corpo could really handle).
Sent you from a third email, third time's the charm eh?
>Anyway, here's a >tl;dr
Thanks m8. Hopefully we can discuss further via email this time.
For now I guess I should setup BUMP again and clone the board?
Been a while since I bodged it to work with debian/devuan (with your fancy melon building ;) )
>in my opinion, the robot chasis is not big enough for a proper brain.
Good point. So from an architecture point of view, would it be better to have N-number of "brain" sub-systems?
The first one actually takes charge, while the others are delegated for additional functionality (vision processing etc.).
From my point of view, only one "brain" sub-system really needs low-level access (CAN) for configuration (power, spine, sensors etc.), while the others can communicate using a high-throughput comms (the internal ethernet network) as they need to write/read much more data for normal operation.
>For that reason, much of the thinking and memory needs to be offloaded into some kind of private cloud
I see the benefits for it, and thus we must also have an open specification for the "cloud"/server component.
Personally I don't want anything to do with internet connectivity, but I admit that for debug/testing and much more complex behaviour, a server connection is required.
What I'll do is probably mention that the Spine will have an external router connected to it via internal network, which then provides the server connectivity. Otherwise the rest of the system must not have any external interface of its own, thus allowing packet filtering and port blocking done on the external router.
As a requirement, the external router must run one of the open source firmwares (Tomato, openwrt, etc.) to be compliant with the RCPS spec. Oh and of course alphabet corp blocked by default :P
>volume thermal considerations
Good reminder. The RPCS spec will not go too far into implementation (other than perhaps the electronics), but a document covering the thermal solutions (perhaps based on content in >>234
) will be very handy. Although in regards to RPCS, thermal management means the spec must provide recommend volume for various sub-systems, as well as spacing between interface ports etc.
>He'll need to enable you to make an account
I'm guessing this for another chap? I certainly haven't used IRC with you before XD