Cool project, well done. I'd suggest that instead of instructing users to clone your Github project and then detailing how to adapt the RPi code to the CHIP computer, rather create a Github branch that has the CHIP-specific diffs, and link to that branch for users to clone instead of the original branch. That way, your tutorial is also more condensed (a good thing, imho).
Yes, I'd echo that. I teach for a living, and it's amazing the number of different ways people can come up with when interpreting what you think is a straightforward instruction. When I read the "delete lines ...." bit, it didn't seem completely explicit, and in addition, I'd think that alone would put a LOT of people off having a go. Much of this kind of thing is generating confidence in people, and if they fall at the first hurdle, it's game over; possibly for their entire lifetime if it happens at the wrong point!
Love getting people into robotics. The problem is that this kit has two motors and some sensors that go into a car, for $199. Not much you can do other than drive or program the car. With starter kits like this one http://www.vexrobotics.com/starter-kit-with-controller.html
you get parts to build a number of different robots. Granted, it's $280, but the extra $80 gets you a lot more learning.
A side note on the chassis. It's similar - not the same - to the ones I've been using in high school classes for a few years. I've bought mine off amazon/ebay for 15$ and while they're good enough to get started they have several weak points: motors are undersized, power supply is too low for 5V boards, assembly is not so good with parts not fitting well. They're certainly not an example of good design. Unfortunately I couldn't find any better option in the sub 100$ range with two DC motors so I understand why OP chose something similar. Does anybody know of a better chassis for these kind of projets?
I got this Arduino bot for $70. Has its own battery for sufficient power. The motor gearing is a bit fast, so it's better to use PWM to slow down the motors, except the default pinout disables PWM on the drive gpios when the servo is enabled. The build quality is ok, except there are no spacers for the bolts between the PCBs and acrylic base, so I worry about damaging the PCB during assembly.
Li-ion battery is much better but I don't need an Arduino board nor sensors - we've plenty of - and I don't get the 4 motors design... more problems and no particular gains.
Al these kits and chassis look like a different mix of the same - not so good - parts.
Disclaimer up front: I have a significant interest in this company and product, so I'm definitely pimpin' my own sauces. :)
With that said, we[0] build a product called MRK-1 which is a programmable autonomous robot built using a custom board we developed using similar technology to Arduino. Our kits are around $100, very simple to build an operate, and we have a sweet textbook written by some awesome guy named blister[1]. :D
We're geared more towards selling to individual schools and school districts, but if you're interested, I can hook you up with a kit and a digital copy of the programming book.
It's an interesting product but I need vanilla Arduino and off-the-shell parts. We build one different robot a year as a final project after a few months experimenting with simpler circuits and components.
We basically are vanilla Arduino and off-the-shelf parts. All our board does is combine the Atmega 328 with a motor controller and has some IR sensors pre-soldered onto the board. The motors, sensors, and even some IO headers are just generic 5v pins.
You program our board using the Arduino IDE and can configure the actual robot any way you want. :)
Does anyone have any experience running some sort of real-time OS on cheap hardware like this? Seems like more high speed control applications could maybe benefit from a really cheap platform to prototype on.
I received two C.H.I.P last week, wanted to take that as an opportunity to learn as well as teach my girlfriend about this kind of stuff. I was looking for an easy project to start with, but couldn't find anything.
This is a Raspberry Pi robot kit called GoPiGo[1]. And this is the biggest problem I've found with the C.H.I.P. - everything you do with the C.H.I.P. is something that can be done more easily on a Raspberry Pi.
It's not an indictment of the C.H.I.P., which is a massive effort (although having played around a bit with two I'm sad to say it has too many problems for me to stick with), but more a testament to the Pi.
The C.H.I.P. has three features I absolutely love compared to the Pi Zero: built-in WiFi, built-in flash, and USB serial console.
Steps to set up a Raspberry Pi Zero on WiFi:
1. buy the Pi Zero ($5), MicroSD card ($5), USB WiFi adapter ($10), and USB OTG adapter ($1) (total = ~$21)
2. flash the MicroSD card
3. either:
a. mount the SD card on your computer and figure out which WiFi configuration files to edit
b. buy a serial cable, open a serial console, configure WiFi
c. buy a mini HDMI adapter + mouse/keyboard, connect to a monitor, configure WiFi
Steps to set up a C.H.I.P. on WiFi:
1. buy C.H.I.P ($9)
2. connect to USB, open serial console, configure WiFi
Point 2 didn't work on my Mac, nor on my Windows box.
I did notice later on that I needed to install libusb drivers for it to work with Windows 10, after installing it to flash, flashing worked but I haven't tried the serial connection yet.
One caveat I noticed is that you need to use 'cu' instead of 'telnet' or 'screen' or the console gets garbled during wifi setup, at least on my machine. Took a while to figure that one out.
Further to other people's posts (and again, I don't want to spend time ragging on this, it's got some really good ideas, the PocketCHIP is definitely an innovative concept and I do want to see this go well), someone posted a thread in the CHIP forum that accurately reflects what I think will be the experience of many people here: https://bbs.nextthing.co/t/a-constant-struggle/12141
I had problems with my C.H.I.P.s not booting fully when the power was not sufficient. They are very iffy that way. Also the WiFi is not great.
The larger PIs, on the other hand, will boot from a potato battery but will corrupt your SD-card doing so. If you can get away with using a PI-Zero (100mA max draw), you should do so. You can basically use anything to power it.
So I don't want to rag on something that had a huge amount of effort put into it, but... (and these buts apply to other systems as well as the C.H.I.P.)
1. The Allwinner chipset was a bad choice. It's non-free, flaky, underpowered (performs worse than a Pi Zero in my non-scientific tests so far).
2. The use of full fat Debian may contribute to 1. I think the AllWinner SBC is more suited to Android phones than general purpose SBC use, and using full fat Debian as a primary OS is potentially throwing away resources on things like a full fat libc. Yes there's Angstrom Linux as an option, but Angstrom's not really well maintained. Again, not limited to CHIP but definitely including it.
3. The PocketCHIP as interesting as it is, is a ballache compared to using a Pi Zero. For a Pi Zero I can install retropie and be up and running in under 10 mins. For PocketCHIP I have to hand configure each emulator, not all the debian packages work (weird segfaults and errors ahoy) and so on. Again, the PocketCHIP is not the only thing that experiences this, but once you've played Pico-8 for a bit, you start to realise that this is the only game in town for this platform unless you're willing to expend serious effort on work already done elsewhere.
4. The flash mechanism. Good god, where do I begin. Firmware flash updates require Chrome to be installed. That's right, the flash updater is a Chrome extension - a web browser extension. This is a ludicrous choice. A web browser is for browsing the web, not flashing firmware onto devices. There is an alternative route buried deep in the docs, but this is pretty convoluted. To flash the firmware in order to get hardware accelerated CPU support, I had to install chrome on my mac, fail several times thanks to the GUI interface clearing errors after they appear, try again with different combinations of USB hub, swear at the damned thing, then repeat the entire process on Windows.
5. I've alluded to this elsewhere, but the Debian build is broken in places. Various packages break because they don't take the architecture into account. Again, this isn't limited to the CHIP, but includes it.
The bottom line is that a $9 computer has a lot of competition depending on target use. Against a Pi Zero it loses to the incredible Pi Ecosystem. Against a Beaglebone it loses to a completely open design. Against a ZSun Wifi reader or plenty of cheap WRT devices, it loses on performance because of the full fat libc and the tightly specialised nature of the underlying distro.
At best (and without some serious work) the CHIP is destined to be a footnote amongst closed and partially broken Pi clones. At worst the PocketCHIP will be forgotten about in a couple of years. It's a shame, from a hardware perspective PocketCHIP has a lot of potential, being pretty hackable. Sure, the keyboard is terrible, the screen's pretty crappy and the peeling plastic is a nightmare, but it's got huge potential. I just don't see the resources there to bring it up to the same level as the Pi ecosystem.
Again, this isn't just limited to the CHIP - we'll see the same thing with the Onion Omega2, we've seen this with the Pine64 and various Pi type devices.
The fact that this post is about a port of a Pi-specific device sadly says more about CHIP's future than anything else.
2. I think you're right but I don't know what the better answer is -- I don't like the idea of raspbian being the only answer. Maybe they'll motivate Debian to improve in this regard?
3. This is a strange comparison. The PocketCHIP is a bit of a unique offering -- I'm not aware of a self-contained anything based on the pi zero that I can order off the shelf and use out of the box. I'd be delighted to see a counterexample!
5. Please report these problems! If not to debbugs, at least make a blog post or a gist or something. Get the information out there!
I agree with most of your conclusions, with the caveat that the Pocket CHIP is a unique device, in a world of years-long any-day-now products. It is very refreshing to see someone accomplish what they set out to do, warts and all.
For point 3, there are options like Adafruit's PiGrrl series, some of which I believe need 3d printing (but you can order that done for you from elsewhere). The downside of the PiGrrl is the lack of keyboard. The upside are the controls are better.
On point 4, yes there are, but this is rather convoluted too. Web browsers are supposed to be used to browse web pages. If they wanted to use javascript to create a cross-platform app, they should've used something like electron.
Point 5 I'll get round to when I have time, but I'm very time poor. I've already started seeing if I can improve mednafen support for Atari Lynx and get the GLES in 4.4 working better with mednafen.
I'm totally with you on the idea of raspbian being the only answer - I really don't like that. Unfortunately many of the problems come from the fact that the Allwinner chip used is so poorly supported and that people don't write code for multiple architectures, so packages build but then you get segfaults over stupid things like endianness when you run binaries.
I take issue with quite a bit of what you are saying, as;
1. The Allwinner chipset is 100% libre at this point [1], and they chose a cheap chip (the R8) so they could not have to subsidize their board unlike the Rpi Zero. If you want a more powerful board, buy an OrangePi PC Plus for $20.
2. "Full Fat" Debian is not very heavy, and you can easily disable what you don't need. The only "fat" is used disk space, which you can easily free up with a quick apt remove.
3. Can't comment much on the PocketCHIP, as I don't own one.
4. You want a secure way to get your OS onto your device, right? Even Signal for Desktop relies on Chrome, its virtually the only universally installable, secure way to distribute an application.
5. I have other A13 based boards and I've yet to encounter package breakage. The architecture is plain jane ARMv7, nothing specifically needs to be changed from the main Debian repos unlike the Raspberry Pi.
>At best (and without some serious work) the CHIP is destined to be a footnote amongst closed and partially broken Pi clones.
Its definitely far from closed, and it has decent software support unlike Pine64 and other failed boards, with the people behind the board writing eMMC drivers and working to build a better BBB. Compared to the BBB it is basically all there at this point.
Whether or not other cheaper boards like the OrangePi Zero wipe it out is yet to be seen though. The Pi ecosystem seems very caustic from what little I've seen with my Pi 3, reminds me of the Android modding community, hence why I've yet to build anything useful with my Pi 3.
1. No it isn't. AFAICT The on-board Mali chipset needs a binary driver for full functionality. Lima's not there yet. I had a quick look at the mali package for 4.4 and it's shipping a binary, not source as part of the debian source package. There are also still issues with crypto acceleration and other areas that aren't accessible through F/LOSS.
2. Full fat Debian is heavy because it uses a full libc instead of uclibc. If you want to see what non-full-fat looks like check out LEDE or Angstrom. Running uclibc will result in lower memory usage and higher speeds. If I had the time I'd port LEDE as a target, but I don't.
4. Browsers browse the web. Firmware update tools update firmware. The two do not need to and should not mix. A secure way to get an OS on my device is to have a tool (for which I can download, verify and compile the source) that connects over a secure protocol to a site where I can download the OS and relevant signatures, verify these signatures, install the OS and verify the installation. Please don't conflate network crypto with hardware. The two are completely different things.
5. It's great that you don't have problems with completely different boards running packages on completely different Operating System implementations, but I'm talking about the CHIP, which runs it's own build of Debian and Debian packages.
As for your comments about software support and whether it'll be wiped out, I feel like you're at least partially missing my point - the Pi ecosystem is a monoculture. It works extremely well from a community support perspective because of that monoculture but (as you highlighted) it's not without it's problems. For long term success, the CHIP needs to puncture that monoculture. I don't believe that it will reach that point.
1. You can boot and use virtually all the hardware, H.265 hardware video decoding included with a fully libre stack. The Raspberry Pi is unlikely to ever be able to do that. Never tried the Allwinner Android builds, mainly cause they are unmaintained.
2. You've got space to work with, you are not limited in terms of space. Feature wise I and many others don't want to make the sacrifices [1] to use a smaller libc, I did it when developing an application on Angstrom using a BBB and I never ever want to do it again.
4. How would you get secure, verifiable images to people by default across every major platform? We all know 99% of the people who both the C.H.I.P. are NOT going to be bothered to verify the signatures by hand, and even then how do you ensure the signatures are from Next Thing Co? A Chrome Extension solves this.
