To learn robotics and eventually program robot brains I’ve started building some ROS2 modules. I have several Raspberry Pi 3B’s so I bought some stepping motors and an Adafruit 16-channel PWM HAT and set about building some ROS2 packages.

Well, I soon discovered that, while ROS2 is a modernization of the original ROS (which grew organically over the last decade plus), it is not all done. There are many, many features, modules, and conventions that are not complete. So, I scaled my project back a little and started building some basic modules so I could learn the state of things.

First thing I published is a fork of Christian’s raspicam2_node which compiles and runs under the latest ROS2 build (bouncy). This lead me to needing a version of ROS2 on Raspbian. ROS2 is targeted at the latest versions of operating systems and tools. So ROS2 wants that latest version of Linux and also wants 64-bit hardware. But everything hasn’t caught up – the latest version of Raspbian is 32-bit and the previous LTS version of Ubuntu.

To build ROS2 on Raspbian, I created a script in ROS2OnPiTools that fetches and builds ROS2 on Raspbian. It takes several hours but it results in a directory that can be copied onto multiple Raspberry Pi’s.

Future blog posts will describe the details of this project but the first step is a ROS2 node to drive the Adafruit 16-channel PWM HAT. So the project ros2_adafruit_pwmhat_node is a simple, Python only node that subscribes to several topics and sets the PWM values on the HAT.

Now that I have stepping motors moving, I will work on capturing images and animating my little camera project. Future blog posts will describe this as it comes together.

Comments

I’ve updated Convoar to version 1.1 and started converting a collection of OARs. These sample OARs are available on a Converted OARs page at https://misterblue.com/oars/ . This gives pointers to various optimized GLTF scene conversions, downloads of all the scene files (ZIP and TGZ), as well as a download of the original OAR file.

There is also a VIEW button which opens another browser page with a simple ThreeJS viewer on that version of the GLTF file. Be sure to close that view page as having several views open at the same time till greatly overtax any graphics card.

I’ve had a lot of luck running Convoar in a Docker image. This has solved most of the problems with getting the correct .Net/Mono environment on Linux machines. Even conversions that crash under Windows 10 (usually out-of-memory) work with the Docker image.

On a Linux system with Docker installed, I do the following:

mkdir /tmp/frog
cd /tmp/frog
cp OARFILE.oar .
docker image pull herbal3d/convoar
docker run --user $(id -u):$(id -g) --volume $(pwd):/oar herbal3d/convoar OARFILE.oar

The --volume parameter maps the container /oar directory to the current directory (which contains the OAR file named OARFILE.oar or whatever you wish). The --user parameter sets user and group IDs of the Docker container to the current user’s so the container can write into the mapped directory. Then the container is run which reads the OAR file and writes all the output files to the mapped directory. If there are any parameters for Convoar, they go before the OAR file filename. When it’s done, you have the original OAR file and all the GLTF files in the mapped directory.

Cool.

Comments

I’ve been working on an OAR file converter. For those of you not in the OpenSimulator community, an OAR file is a region archive format – saving the contents of a region for loading into another region. So it contains all the meshes, textures, scripts, and assets that completely define a region’s contents.

Convoar reads an OAR file and outputs a GLTF scene and image files containing most of the region information. Most specifically, textured mesh representation of all the objects described in the OAR file.

Convoar is evolving. The current version reads an OAR file and outputs either an unoptimized GLTF scene file or a “material reorganized” GLTF scene. The output GLTF is not packed or binary so the output GLTF is a JSON .gltf file, one or more .buf files (containing the vertex information), and an images directory with the texture files for the mesh materials. By default, the output textures are either JPG or PNG format depending if there is any transparency in the texture.

The unoptimized GLTF conversion is a simple conversion of the OAR primitives which creates many, many meshes and is very inefficient for rendering but is good for editing (importing into Blender, for instance).

The “material reorganized” scene has object corresponding to each unique material (texture/color/features) and the meshes have been assigned to each of these material objects. This renders the scene uneditable but this should greatly reduce the number of draw calls needed to render the scene in OpenGL/WebGL.

Future versions of convoar with either contain or have tools to perform other optimizations to the scene and the object therein.

Roadmap-wise, Convoar is a first step in developing code that makes OpenSimulator content displayable in a web browser.

Comments

Haven’t posted in a while. Well, really, no one reads my little blog so no one has missed my missives.

To catch up:

After doing some work on region simplification (for displaying OpenSimulator regions in a browser), I’ve been trying to create an OAR to other format converter. OAR files are the region archive format of OpenSimulator. The OAR file reading code is in C# (the native language of OpenSimulator ). I started thinking that the best output format would be GLTF since it was new and upcoming. There are conversion toolsets in the Cesium project and it looked like the browser world was moving there.

Well, I ended up writing my own GLTF format exporter and had it more-or-less working with ThreeJS.

Then, the GLTF standards group decided that the world needed a version 2 of the GLTF format. Over many months (and I mean MANY), the standard and then all of the tools in the pipeline converted from GLTFv1 to GLTFv2. Then there was the wait for the GLTF extensions to convert to version 2. As of this writing, I’m not sure all the tools have caught up.

It then occured to me that I could use an existing format conversion library to convert the OAR scene to many different formats. So I found Assimp that reads and writes many different 3D formats. One problem with that choice is that Assimp is a C++ library and, as mentioned above, I was working in C#.

An interface library was required so I found Assimp-net. Well, actually one of the forks of Assimp-net which had been updated recently. But it had been updated to the most recent Microsoft C# framework which, it turned out, was not yet supported by everything.

Sigh. It is frustrating spending time playing with tool versioning when I just wanted to do some 3D object conversion. It feels like I started the day trying to build a house. But, to build that house, I needed a hammer. So I needed to research what hammer options were available. To get the hammer option I needed, I had to then study forging and how to forge the type of hammer I needed. Finally, after weeks of researching hammers and forging and where to dig up the iron oar, I look up and there is still the empty lot where my house should be.

I’m shelving that project to let the tools mature a bit. In the mean time, it’s off to building robots!

Comments

An update to BulletSim has been checked into the OpenSimulator that upgrades BulletSim with version 2.86 of the Bullet physics engine as well as fixing some known problems.

Mantis 8010 (“BulletSim does not always call collision events on collisions”) was caused by BulletSim not doing collision detection on all of the physics engine sub-steps. This meant that fast moving objects (like bullets) could bounce off of a target without reporting any collisions. For those into details, any OpenSimulator physics engine is called every tenth of a second to simulate the next tenth of a second of time. BulletSim internally steps 10 times within that tenth of a second to do a higher resolution physics simulation – a tenth of a second is a long simulation step but that’s the way OpenSimulator does it.

Mantis 8011 (“BulletSim fails to send land_collision messages on some terrain”) was caused by BulletSim computing terrain height differently than the mesh in the physics engine. So, an object on steep terrain could compute as underground to some code while appearing above ground in other code. BulletSim prevents physical objects from going underground by pushing them up when the do. This check would sometimes cause a falling object to float over terrain rather than colliding with the terrain.

The problem in Mantis 7132 (“Collisions stop for no apparent reason on BulletSim”) hasn’t been explicitly fixed. Still looking for that problem.

I found an additional problem that collision_end events don’t happen if the colliding object does an llDie() on its collision. For instance, a target object wouldn’t get a collision_end event for a bullet object that hits the target and does an llDie() on its collision. It looks like the ODE and ubODE physics engines don’t exhibit this problem because of the order that collisions are reported to the simulator. The fix is some code re-organization in SceneObjectPart.cs.

Still in the pipeline is the proper implementation of PhysicsShapeType and then physics engine implementation of raycast.

Comments