The robots are coming (virtually)

Yes, it’s several years since I last posted anything. But I think this might conceivably be useful for somebody, in a very specific set of circumstances.

Install ROS and baxter emulator on WSL

This is a fairly detailed set of steps to install ROS Noetic and the Baxter SDK and its 3d graphical emulator on a Ubuntu system running in Windows, to allow development of ROS applications for Baxter without a real robot. It’s mostly written down to help me remember the steps I had to go through to get everything working with WSL and Noetic even though the Baxter SDK has been prtty much abandoned and doesn’t support newer versions of ROS. It’s actually not that hard, but there area a lot of steps. I hope you find it useful.

Some of this comes from Setting up ROS in Windows through WSL2, and some from Baxter workstation setup, and more from Github. Other bits I’ve worked out through trial and error and a number of web searches.

Preparation

I’m assuming you already have the Windows Subsystem for Linux version 2 (WSL2) installed on your windows PC. If not, then this won’t be much use. I’m also assuming you have a Ubuntu distro installed (I’m using 20.04) and the Windows Terminal as an interface to it.

Install X VxXsrv server to allow gui apps

VxXsrv is an XWindows server program which runs in windows, so the WSL Ubuntu instance can use it as a front end for graphical applications. It works really well.

NB: This bit is done in Windows.

From sourceforge download the installer and run it. When the install is complete, run VxXsrv and on its first run make sure ‘Native OpenGL’ is not selected, and ‘Disable access control’ is selected. Save the config for future runs.

Use ifconfig to find the ip v4 address of the the windows machine, because you’ll need it for the next step (in WSL)

From here on, work in your Ubuntu instance through the Windows Terminal

Configure display in WSL to use X server

Add the display config to your bash script

echo 'export DISPLAY=999.999.999.999:0.0' >> ~/.bashrc

Replace 999.999.999.999 with the ipv4 address you found in the previous step. Note that this may change if you are on a wifi network, and it will need to be reconfigured every time it does.

Make the config active

source ~/.bashrc

Optional: test the x server

sudo apt update
sudo apt install x11-apps
xcalc

If all is well, you’ll see the xcalc running in an X window on your windows desktop

Install ROS

Make sure everything is up to date

sudo apt update
sudo apt upgrade

Add ROS package information to sources list

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'

Add the keys to allow these extra sources to be used. Install curl if it’s not already present, then use it to download keys

sudo apt install curl

curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo 
apt-key add -

sudo apt update

Install ROS Noetic:

sudo apt install ros-melodic-desktop-full

Prepare for ROS use by configuring bash script

echo "source /opt/ros/noetic/setup.bash" >> ~/.bashrc
source ~/.bashrc

Install development packages

sudo apt install python3-rosdep python3-rosinstall python3-rosinstall-generator python3-wstool build-essential

When it’s done

sudo rosdep init
rosdep update

test it!

roscore & rosrun rviz rviz

Create ROS workspace

mkdir -p ~/ros_ws/src

Source ROS and build

source /opt/ros/noetic/setup.bash

Build and Install

cd ~/ros_ws
catkin_make
catkin_make install

Install Baxter SDK

cd ~/ros_ws/src
wstool init .
wstool merge https://raw.githubusercontent.com/RethinkRobotics/baxter/master/baxter_sdk.rosinstall
wstool update

Source ROS setup

source /opt/ros/noetic/setup.bash

Build and install

Be prepared for this to fail with errors!

cd ~/ros_ws
catkin_make

Don’t worry. Because we are now using Python 3, some of the scripts need a bit of tweaking because they are using Python 2 syntax.

in file ~/ros_ws/src/baxter_interface/src/baxter_interface/robot_enable.py, find a line which says

except OSError, e:

and change it to

except OSError as e:

Then try again:

cd ~/ros_ws
catkin_make
catkin_make install

Set up ROS workspace

Download the baxter.sh script. This will set the right parameters for ROS to communicatwe with the (emulated) robot.

$ wget https://github.com/RethinkRobotics/baxter/raw/master/baxter.sh
$ chmod u+x baxter.sh

Customize the baxter.sh script

Edit the baxter.sh shell script making the necessary modifications to describe your development environment. In WSL, th linux system will probably have a different IP address to the windows PC hosting it. This is absolutely fine for the baxter simulator, but you need to know what it is. The hostname comand will tell you:

hostname -I

Using your favorite editor (you’ve got an X server now, so you could use xedit) edit ~/ros_ws/baxter.sh and make the following changes:

Edit the ‘baxter_hostname’ field

baxter_hostname="baxter_hostname.local"

Edit the ‘your_ip’ field. Modify where ‘your_ip’ is the IP address of your PC.

your_ip="192.168.XXX.XXX"

Modify ‘ros_version’ to noetic:

ros_version="noetic"

Save the file.

Initialize your SDK environment

From this point forward, your ROS environment setup should be as simple as sourcing the baxter.sh script from the root of your Catkin workspace:

cd ~/ros_ws
. baxter.sh

"Should". What a great word.

Getting it all to work

Install the baxter simulator

cd ~/ros_ws/src
git clone https://github.com/RethinkRobotics/baxter_simulator.git
wstool merge baxter_simulator/baxter_simulator.rosinstall
wstool update

Install other dependent packages:

cd ~/ros_ws/src
git clone https://github.com/ros/xacro.git -b noetic-devel
git clone https://github.com/ros/roslint.git

Build everything

Expect this to fail!

source /opt/ros/noetic/setup.bash
cd ~/ros_ws
catkin_make

The emulator uses the Qt4 user interface library, but this has been superseded by Qt5 and is not installed by default. So it needs to be manually added (unless you fancy editing all the files which use it and converting them to Qt5). We need to use a third party PPA to do this:

sudo add-apt-repository ppa:rock-core/qt4
sudo apt update
sudo apt install qt4-default

Then try catkin_make again:

catkin_make

And once again, it will fail. There appear to be loads of errors, but in fact there are only two files which need to be edited:

1. ~/ros_ws/src/baxter_simulator/baxter_sim_kinematics/src/arm_kinematics.cpp

Edit the lines which says

boost::shared_ptr<const urdf::Link> link = robot_model.getLink(tip_name);
boost::shared_ptr<const urdf::Joint> joint;

to read as follows (i.e. replace the reference to the boost libraries with the std one).

std::shared_ptr<const urdf::Link> link = robot_model.getLink(tip_name);
std::shared_ptr<const urdf::Joint> joint;

2: ~/ros_ws/src/baxter_simulator/baxter_sim_hardware/src/baxer_emulator.cpp

Edit the lines which says

cv_ptr->image = cv::imread(img_path, CV_LOAD_IMAGE_UNCHANGED);

to read as follows (updateing to match changes in the OpenCV library).

cv_ptr->image = cv::imread(img_path, cv::IMREAD_UNCHANGED);

Then try catkin_make again, and assuming it works (you might get some warnings, but you can ignore them) do catkin_make install

catkin_make
catkin_make install 

Time to try it out

Use the baxter.sh script with the ‘sim’ parameter to set up parameters for simulation rather than a real robot.

cd ~/ros_ws
.\baxter.sh sim
roslaunch baxter_gazebo baxter_world.launch

And it fails again. This time it’s a ROS launch file which needs modifying to use xacro instead of the old xacro.py. Edit the file ~/ros_ws/src/baxter_simulator/baxter_gazebo/launch/baxter_world.launch and change the section below

<param if="$(arg load_robot_description)" name="robot_description" command="$(find xacro)/xacro.py --inorder $(find baxter_description)/urdf/baxter.urdf.xacro gazebo:=true"/>

removing the ".py" from the xacro command:

<param if="$(arg load_robot_description)" name="robot_description" command="$(find xacro)/xacro --inorder $(find baxter_description)/urdf/baxter.urdf.xacro gazebo:=true"/>

That’s it. You sould be good to go, now. Run the following command

roslaunch baxter_gazebo baxter_world.launch

And you should see Gazebo fire up, with a model of Baxter in it, and also a window showing emulations of the arm and body control dials and buttons. Note that these are running alongside any other Windows apps! It’s a bit like magic.

You can now open otehr Windows terminal sessions to the same Ubuntu instance and run other ROS nodes to control the simulated robot. As with a real robot, you need to enable it using the enable_robot script fromt eh baxter_tools package before it will do anything. You can also run the standard sample demos, e.g. the arm wobbler:

./baxter.sh sim
rosrun baxter_examples joint_velocity_wobbler.py

Though you might need to edit the first lines of python files to ue Python3 instead of python or python2. And in enable_robot.py you’ll need to correct the syntax of an exception handler and a print statement. But they are left as simple exercises for the reader 🙂

The sons of Martha

Rudyard Kipling wrote a poem called ‘The sons of Martha‘ which is a gentle hymn of praise to those in society whose graft keep things going while others enjoy themselves. I like to think it’s about engineers. It contains a line which I really like: ‘They do not preach that their God will rouse them a little before the nuts work loose‘. If I’d paid a little more heed to that, I wouldn’t now have a pile of wreckage rather than a working drone. I failed to properly tighten the propeller nuts, and sure enough one came loose at altitude. It makes for an amusing video (I hope I haven’t given away the ending), but it may be a little while before the drone flies again.

Making things to make things to make things

I recently acquired a woodturning lathe. Unfortunately, it was missing a rather important part – the centre drive head, which grips the wood being turned. It’s not huge or complex. It just looks like an elongated nut with spikes on one end which grip the wood being turned. At the other end is an internal screw thread, which fits on to the drive shaft of the lathe:
drive_centre 1
Because the lathe is old (you can tell from the black and white picture), the manufacturer doesn’t sell the spare part any more. They don’t seem to appear on eBay, presumably because anyone with a lathe isn’t going to sell such an important component. If I had any significant metalworking machinery, I could make one – but I don’t (yet). I do have a 3D printer, however.

I didn’t do any stress analysis on the component, but my instinct told me that a printed part wouldn’t going to be strong enough for this job. The centre has to hold a largish lump of wood spinning at up to 3000rpm. It has to do this while the wood is carved by a chisel, and most importantly it has to do this while I am standing very close to it. It’s not allowed to break. The body of the part needs to be reasonably strong, and the spikes on the end doubly so. It’s not really printable unless you have a SLS metal printer. If I could afford one of those, I wouldn’t be buying an old second-hand lathe.

My solution was to cast a new component, and to 3D print the mould for it. Some years ago I came across Plastic Padding Chemical Metal, which is a two-part polyester resin filled with metal powder. It’s designed for repairing things, and it’s very strong when it sets. I’ve mended various things with it over the years, and none of them have ever failed. I thought I might be able to use it to cast a new part. My wholly unscientific feeling was that it ought to be strong enough for the body of the thing, but probably not for the spikes. For that purpose, some hardened steel masonry nails might do the job. Casting would allow me to embed the nails in the part, and to create the required femall screw thread by simply casting around the male one.

I used OpenSCAD to design a three part mould, and printed it:
mould_01

This is actually the Mark III version. The first two did not have a separate end piece, and I eventually realised that once I had filled the mould with resin and put the nails in, I would not be able to separate it. Doh! One thing to bear in mind is that Plastic Padding is sticky. It’s designed as a repair material, so it’s intended to stick to things. I didn’t want it to stick to the mould, or to the screw thread on the drive shaft. To stop this, I lined the mold with sellotape, and covered the shft’s screw thread with a layer of PTFE plumber’s tape. You can’t beat a good bodge. Here’s how the mould looks, half assembled and almost ready for filling:

mould_02

And here it is fully assmbled and filled with sticky goo, waiting for it to set:

mould_03

After 20 minutes, I opened up the mould (you’ll have noticed the carefully-planned slots on the mould join line, for levering it apart) to reveal this mess:

mould_04

Which eventually delivered a component which clearly needed a bit of cleaning up:

mould_05

But it works! Just for entertainment, I mounted a 2″ square section block of cheap pine, and turned it into one of the roughest spindles you’ll ever see – but the Plastic Padding component worked fine:

mould_06

Now I just need to learn how to turn wood properly…

Incidentally, I’m not sponsored by Plastic Padding. I’m not averse to them sending me a free pack, either 😉

Happiness is a clean head

I’ve not posted much about 3D printing for a while, largely because I haven’t ben able to get my printer to make a decent print without a lot of fiddling. Prints were rough, structurally weak, and generally unsatisfactory. I Tried all sorts of kludgy fixes, but nothing seemed to work reliably. I was beginning to think that the filament I was using was beginning to degrade (some of it is a year or more old). Then I had a conversation with a colleague about the 3D printers (Ultimaker II’s) at work. They were suffering similar problems, and were returned to good operation by replacing the print heads. It turns out that with sufficient usage, the tiny hole in the hot squirty nozzle (that’s a technical term) becomes both worn and partially blocked with overcooked filament residue. It’s a bit like the virtually indestructible stuff which accumulates on the the tins in which you roast vegetables. You do roast vegetables, don’t you? This (blocked nozzles, not ineffectually-cleaned roasting tins) results in a number of problems:

  1. Low extrusion rates
  2. Filament feed skipping, because it can’t push the filament hard enough
  3. Erratic extrusion

At work, we’ve started to think of the print head (or at least the extrusion nozzle) as a consumable item, to be replaced routinely after an as-yet undetermined quantity of filament has been extruded.

Why, I thought, couldn’t I try this at home? No reason at all. Apart from anything else, hotend technology has improved since I bought mine. It seems the generally-accepted best DIY print head is the e3dv6. It’s cleverly designed to separate the hot part from the rest by as small a thermal bridge as possible, and also has a built-in fan to keep the cool part cool. And unlike my old hotend, it’s got a separately-replaceable nozzle. So if (when) it does clog or wear out, it will be cheap to replace.

e3dv6

I bought one. Naturally, it needed a new part printing to fit it on to Richmond, but that was easy. And guess what? It works brilliantly. In a stroke, I’m back to creating smooth, accurate prints. Indeed, I’m tempted to say that the quality is better than the J-Head generated when it was new. I’m really quite chuffed.

ESP8266 happiness

It just goes to show that perseverance sometimes pays off. It turns out that the reason I couldn’t get the Olimex esp8266 to work properly was that my USB/serial converter was faulty. The replacement one arrived today, and now I can program the wifi module using the arduino IDE with no problem. Five seconds after programming it, it had connected to my home network and was sending temperature readings via MQTT to my raspberry pi server. There are plenty of IO pins exposed on the Olimex module, so I can do lots more with it than with the wi07c module I was using before. Watch this space.

ESP8266 disappointment

I found a very promising new ESP8266 module, from Olimex (a Bulgarian company).

MOD-WIFI-ESP8266-DEV-1

It’s a breadboard-friendly board with an ESP8266 and 512k of flash memory on it, and it’s dead cheap. There’s even a carrier board for it, with a relay and a reset button, also dead cheap. I bought a couple, because it exposes all the pins from the microcontroller, so I can (a) use more than one I/O, and (b) hook up the reset pin so that I can put the device into (and, more importantly, wake it up from) deep sleep mode to extend battery life. There are videos on line of how simple it is to program these devices using the new arduino IDE.

The (insert strong adjective here) problem is that I can’t (insert strong adjective here)-well get it to work. I can connect it up to my PC fine. I can even put it into flash mode perfectly well. In neither case will it respond coherently to anything sent to it from the PC. In ‘normal’ mode, it just repeatedly sends the word ‘Error’ over the serial link, and does not respond to any AT commands.

Olimex ESP8266 errors

In reflashing mode, it simply fails to respond to the reprogramming commands. I’ve tried two of these modules, and both behave the same. I’ve contacted Olimex both by email and on their forum, and had no response. It’s a shame, but I think these modules are destined for the rubbish bin. At least they weren’t expensive.

Update: Olimex have got back to me, and have made some helpful suggestions. They don’t know what the problem is, though, and it’s not one they have seen before. It may well be something to do with my serial adapter. I have another on order, so I guess I’ll find out in due course.

The King is dead. Long live the king!

For a while now, I’ve been playing with the super-cheap esp8266 WiFi module. It’s been a bit of an uphill struggle, mostly because of the poor documentation (actually, that’s not fair – the documentation may well be excellent, but my understanding of Chinese isn’t) and the lack of easy programming tools. Until now, there have been essentially three ways of using the module:

Serial for breakfast

The initial method was to control the module via a serial link. As supplied, it can communicate with an arduino (or anything else) using a simple serial connection, using AT-style commands which will be familiar to anyone who has worked with modems, especially GSM ones. It works, but it’s a bit clunky. By and large, I think people have stopped doing this.

C for elevenses

Pretty soon after it became available, smarter people than me figured out that the module is powered by a general-purpose microprocessor (and a pretty powerful one at that). It also became apparent that you could reprogram this directly, and use its spare capacity (and spare I/O pins). Thanks to the manufacturer’s release of an SDK, it became possible to write code directly on the module, without the need for an arduino or any other processor. For less than five pounds, you could have a general-purpose microcontroller with build in WiFi.

Of course, there’s a catch. The tool chain required to do this programming is hard to set up and complicated to use. It also means programming in C and understanding a pretty complex SDK. It’s not particularly friendly. There were some valiant efforts to make this easier, notably Mikhail Grigorev’s bundling of everything into the eclipse IDE. This works well, but it still requires you to program at quite a low level.

lua for lunch

More recently, there has been nodemcu. This is a new set of firmware for the esp8266, which builds in an implementation of the lua language, with the SDK functions wrapped and easy to use. Nodemcu allows you to write programs in lua, upload them to the esp8266 and run them on it. This works pretty well. I’ve had temperature sensors in my house using it for a while, It has some drawbacks, principle amongst which is that the nodemcu firmware takes up quite a lot of the available memory, leaving fairly little for your programs. Add to this the fact that your programs are sent to the device as source code, and interpreted (or compiled) in place, and you find that there really isn’t much space to write more than simple programs. This shouldn’t be an issue for small sensor nodes, but I found myself scratching around trying to save a byte here and a byte there just to get my code to run.

Arduino for dinner

What everyone has been secretly waiting for, of course, is the ability to program the esp8266 like an arduino. And now we can. There’s a new version of the arduino ide 1.6.1 which gives you the ability to program the esp8266 using familiar arduino code. The wifi functions are easily available, as are most other arduino functions. It’s insanely easy to write something which connects to a wifi router, gets an ip address and sends data to a server. Or indeed to run a server on the device. Because the arduino language is compiled to native code before being uploaded, there’s loads of space for programs. Some of the normal arduino libraries have not been ported yet, but I’m sure they will be in the coming weeks. I won’t be going back to any of the other methods. Long live the king!

It’s worth repeating that the esp8266 gives you a tiny board with a 32 bit processor running at 80MHz, at least half a megabyte of memory (my recent olimex ones have 2MB), multiple IO pins and wifi for less than five pounds. If I were arduino (whichever half of arduino you care to pick) I’d be worried.

Printed lathe parts online

Since I posted a video of my 3D printed lathe on YouTube, the video has now been viewed over 100,000 times. If a typical working day is 8 hours, and the working year is 250 days or so, then it’s the equivalent of about two solid years of someone watching it. That’s not a job I’d want.

assembly2

Anyway, a number of people have asked for the STL files so they could make one themselves. I’ve finally got them in some sort of order, and you can now download a zip file with them all from here [wpdm_package id=’423′].

If you haven’t seen the video, here it is:

Never mind the Buzzclock

Fair warning

So far, only one person I’ve told about this project thinks it’s a good idea. Everyone else looks at me wtih a mixture of pity and puzzlement, neither of which emotions seems to be mitigated by my explanation. Clearly, the best thing to do with the project is to bury it quietly, and where better to commit something to obscurity than on my blog?

A little bit of background

My eyesight is rubbish. With glasses on, I can see perfectly. Without them, I’m as blind as a bat. When I go to bed, I take off my glasses. If I wake up in the middle of the night, I am unable to find out what time it is without putting my glasses back on and looking at an illuminated clock. The problem is, that by the time I’ve done this (and waited for my ageing eyes to focus properly), I’m fully awake. If it turns out that it’s far too early to get up, it can take ages to get back to sleep.

The usual suggestions

Most people say “Can’t you get a clock with a big display?” It’s a logical suggestion, if you can see well. For me, the digits on a bedside clock would have to be about a foot tall for me to be able to read it without glasses. Others say “Can’t you turn on a light?”, but doing so brings me to full wakefulness (and runs the risk of disturbing my wife). Fools suggest “Can’t you just use an alarm clock?” I do. But if I wake up before it goes off, I want to know if it’s three hours before, or only one. If it’s only one, I’ll get up and do something useful.

The solution

Here it is, in all its glory:

buzzclock01

No, it’s not the internet. It’s the Buzzclock. To use it, you press and hold the button on the top. It then tells you the current time by silently vibrating: one pulse for each hour, then one shorter pulse for each ten minutes past the hour. There is virtually no noise, no light and best of all no need to put on glasses. The time is not accurate to the minute, but it’s good enough to make the decision whether to get up or to go back to sleep.

Don’t laugh, it hurts my feelings.

Inside the box

buzzclock02

It’s a bit of a squeeze. The brains of the device is an arduino Nano, connected to a battery-backed real time clock. The Nano is a very useful device – more or less the same functionality of an arduino Uno or Leonardo, but in a much smaller package. It’s also dirt cheap (about three of your earth pounds). You can plug it directly into a breadboard for prototyping, and then when you want to build the final device, you can solder it in to a PCB or stripboard, or you can plug it in to a terminal block breakout board, as I did.

nano
nano adapter

The real time clock (RTC) module I used came from ebay, and also cost about £3. It uses a DS3231 chip, has a rechargeable backup battery and (unnecessarily) has 32k of flash memory on the same board. I guess the flash is there in case you want to use it for datalogging. The RTC chip also has a built in thermometer (I don’t know why).

ds3231-1

ds3231-2

The RTC and the arduino communicate over the two-wire I2C interface. This makes the wiring really simple. There are handy arduino libraries available to do all the heavy lifting. Thsi is a good thing, because the RTC chip has its own protocol for getting and setting the clock time, and the libraries wrap this into a nice simple set of commands.

The final component in the build is the vibration motor. This is one designed for mobile phones. As usual it’s from ebay and cost about a pound. This is a thing of beauty. It’s a small dc motor (it runs off 5V – the arduino can power it directly from an output pin) with an eccentric weight on its output shaft. When the motor spins, it vibrates. There is nothing special about that, except that it is tiny. The whole assembly is only about 10mm long. The engineering that goes in to mass producing those must be just staggering.

motor

How it works

THe button is just a push-to close switch. As long as you hold it down, the arduino gets power. Let it go, and the power is cut. This way, the arduino uses no power at all when not in use. The RTC has its own backup battery, so it keeps track of time without using the main battery.

Every time you press the button, the arduino boots up. It then contacts the RTC to get the time from it, and sets its own clock. The output pin connected to the motor is brought high for half a second then low for half a second for each hour in the current time. After a full second pause, shorter pulses are used to indicate the tens of minutes after the hour. And that’s all it does. At four o’clock in the morning, when all is pitch black, its a very quick way of working out it’s too early to get up.

Setting the time

At the moment, you can only set the time by connecting the arduino to a PC and sending a string over the serial port. This is not a big deal, because the RTC keeps time over a long period. It’s only an issue when the clocks change to or from daylight saving time, and I can cope with the effort twice a year.