I always wanted the Omnibot to be able to actually grab and lift objects. So I started with the arms and recycled the 2 DoF shoulder servo pack from Trashbot.
The original two arms of the Omnibot 5402
The goal was to get the should parts replaced in a lean looking way. However, the original arms only move forward but not sideways, i.e. Omnibot cannot hug. Adding a second degree of freedom will thus inevitably broaden its shoulders:
Increaing distance between arm and body when using two servos
One trick was to hide the hugging servo within the body as good as possible. A next iteration could also hide the lifting servo a bit in the upper arm. For the current version, I chose to add it on a newly designed base plate that is at least slimmer than the inner should cover (compare it to the underarm):
Close up of the 3d printed 2 DoF shoulder joint on the Omnibot 5402
Here’s an earler version of the design, before I moved the should into the corpus:
Trashbot’s shoulders re-used in the Omnibot 5402
Software wise, I had to slow down the servo speed as otherwise Omnibot would move like this:
Single arm of the Omnibot 5402 moved by two servos without speed control
The final result are the two arms, each controlled by a thumbstick of the Bluetooth game controller. I added the Adafruit servo HAT to the stack that was using the motor stack before:
Omnibot 5402 moving two arms on two different axes using a bluetooth gaming controller
One of the things that are not making me happy is that Omnibot’s belly is to bold that it can’t close the arms and the arms are so short that they can’t lift anything that is in front of it. Fixing these two “bugs” would mean a complete redesign of the arms, I fear.
When i was a child, I was dreaming of the Omnibot 5402, I loved its size, its ability to be radio controlled, it could speak and it could record movements on a built-in tape recorder and it could carry things. A perfect companion!
When you get older, you can make some of your youth dreams come true. So two years ago, I was lucky to get not only one, but two Omnibots on Ebay for 99$ (tax and shipping summed up to another 200$, though 😀 ):
I cleaned the battery compartments of the remote control and the white one and made sure that these work properly, I replaced the original batteries with 2S 7.4V LiPos and bucket converters (max 20 Amps for the Omnibot itself):
1800mAh 7.4V LiPo and bucket converter and barrel connector for the Omnibot 5402
Battery and converter built into the Omnibot 5402
But the real fun starts with the yellow Omnibot:
I wanted to have a Raspberry Pi controlling it,
a decent Bluetooth remote control with more options,
the arms moving,
a camera for computer vision
USB sound card with a loud speaker and a microphone
LED matrix eyes for emotional expressions and to indicate where the robot’s looking at
So, the journey starts with decomposing it and enjoying how it is constructed:
Base of the Omnibot 5402 including all wheels, gearbox and motors
That’s the lower part containing the four wheels that are driven by two motors in the gear box.
The four wheels of the Omnibot 5402, the belts light greay have flattened over the years.
Of course, we want to keep the robot as original as possible, so I needed a H-bridge controller to control these two motors.
Omnibot 5402 gearbox and motors openOmnibot 5402 gears taken out for cleaningOmnibot 5402 gearbox connected to the Adafruit Motorshield and the Raspberry Pi 3
I took the original cable from the Omnibot’s motherboard and connected it to a Motor HAT from Adafruit. In that way, it was easy to use their examples to control the motors using Python.
Omnibot 5402 gearbox controlled by Raspberry Pi and Adafruit motor HAT
Next I’d build this into the base, add LiPo power to the motor controller and USB battery power to the Pi:
I decided to use the D-pad to control the Pi since I wanted to use the thumbsticks for the arms. The D-pad can be used to drive the Omnibot like a tank, forward lets both motors go forward, rotation on the spot can be achieved by turning the motors in opposite directions. Since the motor control is PWMed, we can also set the speed so that the speed is independent of the battery level.
There’s certainly an emotional connection to EPOC, the precursor of Symbian OS that was running the high end devices of NOKIA a decade ago. EPOC was initially developed by PSION who kind of pioneered mobile computing (at least here in Europe) with decent keyboards.
Whenever you research about mobile computing all aficiandos praise the quality of the PSION keyboards. Especially the 5 Series are great – so I heard.
But when you look at the device, there is so much love to detail and passion in the design, for example see the hinge:
Actually, I want to build a little computer to write Python programs on the go. My experience with my previous, smaller design, the PocketPi, was that it is actually to small (keyboard and screenwise) to really write code and think about it.
The PSION keyboard is really nice and the 6inch screen is kind of nice, too. There’s even a Python port for this granddad. But I decided to build my own little device, so a Raspberry Pi would be the right computing platform.
Recently, some new displays are available on the market that save the whole HDMI cables and possible additional screen controller boards. These connect directly via a flat cable to the onboard DSI screen interface of Raspberry Pis. This saves a lot of space an height.
You see the USB and HDMI plugs on the left of the 7in screen, missing on the lower screens, these have the flat cable plugs on the board on the right hand side. So for this build, I used the 7in DSI screen that also includes capacitive touch (60€, 800×480 resolution). Both, display and touch functionality are supported by the OS out of the box.
Finally, I also bought a series 5 keyboard on ebay because I wasn’t able to slaughter the functional one that I bought before. There is a guy who tried to fit a Raspberry Pi into the original series 5 case, but he didn’t get very far. What he achieved however, is to design a little PCB containing an Arduino 32U4 (Leonardo compatible) that translates the keyboard’s signals to a USB-HID keyboard profile. It’s about 40€ (adding to the 90€ I paid for the keyboard and the screen).
Finally I chose the Raspberry Pi 3a+ that has runs on a 1.4Ghz quadcore ARM and includes Wifi and Bluetooth. I love that device because it doesn’t have to many plugs (like LAN or quad-USB like the Pi4), so it’s flat and light. It also includes the DSI port while the Pi Zero W doesn’t.
So this is the final “build” (or rather “composition”, I used a gaffer tape to attac the keyboard to the screen):
So, while the screen itself is about 10mm thick, the Pi 3a adds another 20mm, which is totally unacceptable, esp compared to the Series 5 original 25mm. The screen incl the screw holes is about 120mm, while the keyboard is about 75mm. The Pi 3a+ has 55mm, so if I design a case, maybe I’d move the Pi to the keyboard and would get a floor of 130mm plus case walls. Not sure yet. Probably will also research a different screen, with OLED these are much thinner and lighter.
Software wise, I had to flash the keyboard with an Arduino script provided by the controller board guy on Tindie. That was easy, but it doesn’t support QMK like the pancake 40% mechanical keyboard I built last week. Doesn’t matter, the mapping is easy enough to change in the source code.
Finally, firing up the system and now the EPOC OS. For the first test, I used the emulation running in the browser. On a PC it boots like in a second, on the Pi 3a+ it takes about five minutes, so this is not an option. But see here:
TL;DR: 14x11cm portable Raspberry Pi Zero W with 3000mAh Adafruit powerboost 1000, Hyperpixel 4inch display, a keyboard and a4 port USB hub. Scroll down for videos, STL files, shopping list.
I always want to be able to carry a little computer around that reduces the outside distractions, like no email, ideally no browser, no messaging, etc. Actually, I enjoy the “silence” that I have with the Raspberry Pis. They allow me to focus on writing software for robots and the like.
Sometimes, you want to code on the go. My second shot in that direction is the StickPi, a little computer without battery but with an e-paper display and a couple of buttons. I actually keep using it, it’s my most used self designed computer.
My first shot hasn’t been published yet: the SlatePi. It is a 5inch computer with a small keyboard and a 4000mA battery, but it seems to be to large for every day use.
So I did another computer: today’s PocketPi. It is the symbiosis of the first two: portable but still a full keybard and a battery included.
It all started with the idea to build a Pi Zero and a display into my favorite mobile keyboard:
I wanted to replace the mousepad with that display.
So at some time, I started to decompose that keyboard to understand how much space is there to actually fit in a Pi Zero W, battery and the display.
the decomposed keyboard and already cut off left part of the PCB and softkeys.
I quickly learned that a) the inclusion of the driver for a ST7735 1.8inch display is cumbersome and the resolution might actually not be nice for really working with it (128×160), it may be better suited for a retroPi machine.
So I decided to use another display that I had at home already which is a 3.5inch display for the Pi (without HDMI) and some more decent 480×320 resolution.
[I also removed the original battery plug and the keyboard’s switch to reduce height.]
However, I didn’t want to increase the size of the device by the height of the diplay and thus decided that I don’t need the left (media-related) buttons of the keyboard:
Another thing was to ideally keep the height of the original keyboard which is about 12mm, but looking at the standard plugs of GPIO displays, it became clear that I need to apply some tricks:
plug deprived display, pi with a plug
I soldered the rails of a DIP plug to the pi, took away the whole plug from the display cutting off the pins to a bare minimum.
great height reduction.
I also decided that I wanted to have a full size HDMI out so I bought shorter and more flexible cables than I had at home and dismantled them:
decomposing an HDMI cable reduces weight and increases flexibility.
Finally, i also wanted to add a decent non-OTG USB to the machine as OTG adaptors simply SUCK.
Different USB hubs to select from.
I actually went with a little board that included the OTG “logic” already and had one USB on the side to actually keep the keyboard receiver and stay within the devices case.
before dcomposing the USB 4 port hub.
During the journey, I decided to upgrade to the final Hyperpixel 4 inch display, with a decent 800×480 resolution. The advantage is the little increased size (4mm) compared to my 3.5inch before plus it can be switched off via GPIO. So this is the evolution of the displays over the project:
1.8 inch, 2.8 inch, 3.5 inch, 4.0 inch
I also added the Adafruit Powerboost 1000 and a rather flat 3000mAh LiPo to the mix. The Adafruit is rather expensive (20-30€) and only supports 1A charging current, I’d love to have a cheaper charger board with 2A at some point in time.
With the power source in place, it was time to wire it all up. Note that I added another switch to the keyboard so that I could switch off the keyboard but let the Pi run for background computations.
As you can see, I wired the USB hub directly to the Pi to save some more weight and space:
Wiring the OTG USB hub directly to the Pi.
Another trick to save height with also the new Hyperpixel display (the plug of the screen is okay, so I needed a new Pi Zero without the DIPs and just short pins), is to solder the pins with the plastic spacer from behind and then remove it plus the excess pin lengths on the back:
After the system was established, it was time to design the case and get a feeling for the locations of everything:
[earlier version with the 7 port USB hub and 3.5inch screen.][earlier version with the 3.5 inch screen and first attempt to make the display switchable.]
A later version then had spacing elements between the components to hold them in place. Also the HDMI output cable was added then:
As mentioned before, the screen switch for the 3.5 inch didn’t work as you could switch it off (cutting off 5V with the physical switch) but not on again since the OS wouldn’t re-recognise the screen then.
So the whole case design (TinkerCad) underwent a couple iterations:
As you can see in iterations 7 & 8, the battery was rotated 90° to landscape and the HDMI cable is going between battery and battery charger.
During these iterations the device grew a bit in dimensions to a final 11x14cm. That’s 3cm more than the original keyboard’s case at 8x14cm. But anyway that’s the price for a 4inch screen with a 800×480 resolution…
designing the holes for the keys is a pain in the butt…
So that’s the currently final layout:
Time to look at the functionality in a video:
FIRST BOOT UP!
As I wanted to take the PocketPi to my easter holidays, I needed trade the flat screw “lips” to be bold and rounded to give the hole thing more stability:
bold screw holders, not nice, but survived the holidays / travel.
I installed Raspbian Stretch lite and added the Pixel desktop plus Geany as python IDE. I also configured two of the buttons to zoom the text in Geany, the right mouse key on the keyboard is really handy, the touch screen works as left mouse button and I added multiple desktops to easily switch between apps. Here’s a video of the currently final device in operation:
Then I came along these USB boards that you can pogo-pin to your Pi Zero which is similar in design to what the guy at NODE did.
When working with a Pi Zero, I wanted to connect via VNC so I can run Pixel desktop and Geany on the Pi to develop and run software. When doing so, you quickly want the Pi to display the Wifi and IP address it’s connected to. I chose an e-paper display from Waveshare (do yourself a favor an buy the balck/white display only, not the one with three colors as they don’t support partial update, i.e. they refresh very slowly!) and bought such a USB power board and attached the Zero to a battery:
Once you have this kind of display, you learn that the physical interaction with the machine is one way: consumption. And immediately, you think that it would be nice to have interaction methods to select a WIFI or shut down the machine or select operation modes, etc.
So I sat down and designed a PCB (not printed but wires on a protoboard with a pretty ideal size), to add some buttons for directions as well as two “shoulder buttons”:
To keep the design compact and as the e-paper display would consume the full GPIO, I soldered the pins on the Pi to go through the PCB:
I chose a wiring that can actually use buttons without additional resistors and so the whole system works with only input ports as well as GND:
This led to a compact design alltogether, see also the first version of a PETG designed case:
There is still room for improvement for the case but right now I’m happy enough with it to actually keep it and write software. Querying the keys is really easy:
Finally see a little interaction of the buttons and the screen here, the software is really simple to query the buttons continually and display values on the e-paper:
(On the top left, you see the Raspberry Pi 3 case with the keyboard integrated, still not happy with that design, that’s why I haven’t published it yet.)
I may venture into actually designing (EAGLE files) and ordering PCBs for the button to make the whole thing more “defined” and better fitting the case.
The next iteration was of course to simply try out the wireless transmission of video. And this doesn’t make sense if you still have the camera attached to yourself, so I “augmented” another project of mine, the rover:
Arduino / RC mixed autonomy Rover
Also I did a little self-sufficient stereo video transmission pack, including the Blackbird 2 camera:
Battery, video sender, stereo camera
And attached the two. I love modular designs where you can recombine your projects easily. So these two simply have two batteries etc. Here’s the full setup:
Oculus Pi wireless streaming video rover setup
Here’s the video:
(Don’t know what the heck Pinnacle Studio was thinking to put the black frame around the video when exporting.)
Strange seems that we seem to get some kind of “interlace distortion” when the car is moving too quickly. I don’t quie know whether that is an artefact from the analog video transmission or from the digitisation process itself:
When playing with this, you intuitively move your head to look around. So I could read out the head movements and send them to the Arduino on the rover to actually move the camera. I’d also need to add another servo to the camera to actually be able to move along at least two axis’. Let’s see…
Cryptic title of a blog post, I know. But I urgently needed to try out my cameras with the Pi3 for the use on the Oculus Rift DK2 (video below). My last attempt to stream video locally into the Rift was successfull, so I wanted more. The initial single 2D camera was a logitech webcam C525 (for 60$)
logitech hd webcam c525
I have two stereoscopic cameras. The Minoru which is “kind of” a cheap camera at about 70€, but then again: not, because it’s just 2x 640×480 resolution… I stripped the camera to reduce its size, weight an volume to actually use it on the Trashbot since I know that it is supported by the Raspbian as a camera.
Minoru Steroscopic Cam, around 70€
I also experimented already with the Blackbird 2, an analog camera for streaming video from drones to video goggles. However, that attempt was not really successful since the camera software on PC (!) was laggy and I was thinking that it may be due to the video capture card Easycap (10-20€).
BlackBird 2, around 180 USD
But let’s see, what happens when I run it on the Pi 3:
Learning: the 190€ combo beats the other two BY FAR in experience.
PS: In the video, you see that I attached the cameras to a different Pi than the one attached to the Oculus. This is because, the Oculus Pi has display settings tuned towards the goggles and I need to invest time to make the config changeable via software to actually switch between the googles and a real external display.
Last time, I was able to get the Oculus Rift DK2 to run on the Raspberry Pi 3, including the head tracking. However, the first interactions showed that it’s cumbersome to work with the desktop (since it’s not distributed on the two eyes but really is using the LCD as one screen) and also to use the keyboard.
Also, in the context of making the Oculus mobile and untethered, it is necessary to have a camera onboard, at least, until I get the XTtion to work. It is interesting that it is not too easy to find software that simply can display a video stream from a local webcam, most blogs just describe how to stream from a remote webcam or make a local USB cam accessible via some webservice.
My last attempt to get a stereo analog cam to work was not really cool since the latencies on a PC plus some weird display software as an .exe were not the ideal setting to really improve things.
So after some research, I found a git repository for streaming a local webcam to a dedicated  view, independent from the desktop. You need to install CMake and libbsd-dev to make it run via:
Also, I was able to install the camera in a nice position without additional mechanics:
cam fits nicely the cables of the Rift and enough space on the straps to lead cables.
Here’s the video walk through with some live feed to see the latency:
Next, I may try to either position the video on one eye, or even double the stream to both eyes. Or I may try to use the Minoru Stereo cam that I’ve been working on last year.
So after yesterday’s compile of the PointCloudLibrary that worked although I couldn’t install some of the files before, I compiled today OpenNI although I was not able to install g++-multilib (following Larry’s tutorial).
Well, the error codes seemed to talk more about errors generating documentation, but I don’t care too much about that since google / stackexchange et al are the best documentation…
Also, the installation worked (within seconds).
Nextup was the installation of the Kinect driver / software package. Then it hailed errors. So, it seems that the g++-multilib is necessary for the SensorKinect package to compile. This will be an adventure to get somehow since it doesn’t seem to be available in Raspbian.
Interestingly, I found in an older tutorial from 2013 the necessity to install g++, not g++-multilib. However, trying to install this just led to the message that I had the latest version already.
In another old blog article, I found another version of this tutorial with an error similar to the one I got when calling make in the Build directory. And luckily, there was a reply by another visitor from May this year that there’s two files to change slightly to be able to compile it.
I don’t quite understand what exactly has been changed there, but I’ll try out tomorrow to see whether this will work.
Recently, I managed to use the Oculus Rift as a display for the Pi 3 together with listening to the gyros via OpenHMD. And I found another instruction to run the XTion RGBd camera on the Pi 3 as well. For the sake of simplicity I set up a new system first and then will “fuse” the two.
First prerequisite in Larry’s tutorial is to add decent swap space on the OS, his OS is Ubuntu, mine is Debian Jessie Pixel and that is done differently. So, on the default Raspberry OS, you change the size of the swapspace in the file /etc/dphys-swapfile where you change from 100MB to 2000MB here: CONF_SWAPSIZE=100. I love stackexchange for that… (after rebooting, the command free -h should show you 2.0 GB of swap space).
Under Raspbian Jessie Pixel, I was not able to install libvtk (sudo apt-get install libvtk5.10-qt4 libvtk5.10 libvtk5-dev). Mono, QT and JDK seem quite heavy (like one GB of space) and I don’t know whether I really need these, I hope not, since I really want to code in python and don’t intend to use QT. I installed them anyways, just to get as close as the recipe would let me ( sudo apt-get install mono-complete and sudo apt-get install qt-sdk openjdk-8-jdk openjdk-8-jre).
sudo add-apt-repository ppa:v-launchpad-jochen-sprickerhof-de/pcl also didin’t work, you need to sudo apt-get install software-properties-common first (see stackexchange again), Then it starts to work, but finally I get “NoDistroTemplateException: Error could not find a distribution template for Raspbian/jessie”. Damn. For fun, I googled Jochen Sprickerhof and found his PCL site. As the URL says, it’s geared towards Ubuntu, so this might explain the error I got. When you google “installing PCL on raspian” you get a couple of descriptions how people did it. So I’ll stick to that should something go wrong…
So I skipped this launchpad part, just to  see how far I’ll get. My feeling was that I wasn’t apt-getting something afterwards (but actually git cloning), so maybe this has not an immediate effect, let’s see. git cloning of the PointCloudLib worked (after user and pwd for git).
Also I was able to run the cmake command and run make. The blog says, it will take about 7 hours to compile, so I go to bed now…
/i/49335/products/2019-02-27T20%3A54%3A20.119Z-20190227_215059.jpg?1606306133)
