I am a techie, always have been, but often my work is primarily writing and speaking about emerging tech, more than making it work. As you will know if you have read Reconfigure or Cont3xt I view everything as a fractal, so the level of complexity required to deal with code and hardware is often mirrored looking at the interaction between systems, companies, markets. Though as a programmer first and foremost, the patterns and the detail making things work (or not) is where the true art and beauty is. As they say those who can’t do teach, those who can’t teach write about it, I like to make that a full loop instead. Those who can teach and can write have to be able to “do” in the first place. Trust me I’m a doctor 🙂
This weekend I dived into a build of the Sparkfun Advanced Autonomous kit added to the Sphero RVR (already a well instrumented and interesting bit of kit that I was very happy to have backed on Kickstarter and mentioned in this post on Basingstoke Techjuice). I didn’t do any step by step images of the build as I spent a lot of the time trying to get my aging eyes to be able to deal with the tiny tiny screws, bolts and wire connectors. I was primarily following the guidance from SparkFun build tutorial
The additional kit comprises of a Raspberry Pi Zero W and a preconfigured SD card for its OS. A camera with 2 servos, 2 x time of flight sensors and a GPS board provide extra inputs and some connector boards to combine the inputs on a mux board and a custom serial shield for the Pi. The shield has a RVR/Serial switch to make it easier to plug directly into the USB port from another host computer.
The kit mounts on a plate that can be added too or taken off the RVR. The key advice was to ensure the UART power lead from the board to the RVR was connected the right way around, the red wire suggested as the 5V side to ensure no blue smoke.
The worst problem I had with the hardware, other then being so small and fiddly, was the ribbon cable to the Pi from the camera. I had managed to pull the small retainers out to put the new cable into the camera and push the clamp back down, but on the Pi I managed to pull the black retainer out completely and it was very difficult to get back in, and may even be a little broken, but seems to be holding. The camera already had a ribbon cable attached, which was initially confusing, but it was clear the one in the tutorial matched the one in the box as it needed to be narrower to fit on the smaller connector on the Pi than a standard one.
It was suggested to set up the Pi first, but also said it could be done afterwards, I went for the latter. Doing s/w config was not as exciting and interesting as building the thing. Once built it all seemed connected and I was getting a nice green light on the Pi. The SD card needed files edited on it to put in the network details, and one other config edit was required. I managed to find a SD card adapter and was able to edit the files on the MacBook Pro. I had thought I could do the setup via the iPad Pro as that’s where the RVR app is, but this is of course outside the normal RVR educational environment so the Mac was easier.
After several attempts and rechecks of everything it seemed the machine was not going to connect to the mesh network. The proxy file that it was supposed to copy over the details with was failing (or just not happening). So I fell back to option 2. Connect the Mac to the serial port board and SSH in. That did not work straight away, I did not see the device when plugged in via the shield, so I tried the usb ports on the pi itself. The one I could reach, as a sensor was in the way, didn’t see to work either. Then I read that is the middle port that needs to be used, and found this article (and the additional steps) very helpful to get it working and then to be able to switch back to the serial shield too. SSH into the device and ran sudo raspi-config and entered the network details remotely, I got a pleasing bing on my watch as a new device joined my mesh network. I was expecting to have 2.4/5ghz wifi trauma, but it all worked out.
It was not all quite as straight forward as when I started to put the thing together, but as I have lots of kit, cables, adapters etc, and residual knowledge of what remote connecting in to linux via ssh actually is it was like being back home. Though, again, as in my novels, my dislike of overly convoluted “all you have to do is type xxxxxyyy.xxx..xx..ss.www” remains. I can do it, always have to look things up, understand why I am doing what I do, but its still based on adjusting to the needs of the tech not the other way around.
Connected and seemingly stable I then ran through some of the Python based tests indicated on the article from Sparkfun. It was here I was brought back to our old favourites, permissions. I tested the servos, camera, gps, and time of flight and all had various permission errors. It may be I have not got something quite connected or ran something out of step, possibly missed some sudo prefixes and created some dodgy files. However, I am not overly worried, it is pretty much put together and now I am back in the s/w config arena, checking a few logs and hacking a few things I should get back on track next time I spend some time on it.
Then it will be into proper code again, with the Sphero Python SDK for the device. It looks as if there is enough stuff on the iPad Pro to be able to engage and code with that, which will be preferable. Stuck with a works windows machine now so the Mac won’t be travelling with me, my iPad Pro on the other hand will.
Wish me luck 🙂 I will try and not make it take over the world. Yes, doing this will inform something interesting in book 3, I am sure of it, as well as helping my analyst day job and any educational stuff I do for STEMnet and BCS 🙂 It also felt really good to be mixing with hands one hardware and software, especially that didn’t work first time.
Leave a Reply