I have been meaning to get this out a long time ago, but this model was characterized by delays, long delays.
This was supposed to be a quick attempt on making a 6 wheeled vehicle with steering on both front and back wheels, and all wheels having power. My initial model is a clear indication of my ambitions with this project:
Somewhere along the road I decided to try to add pendular suspension and it slowly turned into a full blown project. Then I started delaying the project, with me not even touching it for periods of up to 6 months.

The steering module is the most important part of the build, with steering and drive being controlled from each side of the axle it suspends on. I tried to keep it small and strong, while including a differential. I tried to figure out how to get the power through the steering, but I didn’t manage to find a solution which was small enough, so I ended up using those Universal Joints. It is not a good solution, as only a little bit of friction actually holds the wheel in place.
To improve the amount of distance the suspension can work with, I made the connection to the spring so it can detach when the spring on the other side is being pressed together.

To keep the overall height of the model down, I placed the NXT motors between the modules, which worked rather well. As a side effect it also gave the build a very low center of gravity. One thing which required special attention was to keep a smooth surface to prevent the modules getting stuck on the motors.
I do really hate the shape of the NXT motors though, it makes them nearly impossible to incorporate them into a space-efficient model.

All in all, I can’t really say I’m satisfied with the build. While the entire model is very robust, the wheels can easily pop off making the strength of the rest of the model kinda pointless. Also the suspension on the middle wheels should really have been something else than pendular suspension, as it causes the front or back wheels to lift off the ground.
One of my goals with the project was to learn how to do wireless bluetooth communication in C++ from my computer to the NXT. I did succeed, but I never got it polished up with joystick support as I wanted…

A long time ago on Mindboards some talk was made about displaying text-output like how it is done in a console, but I never ended up writing any code. Since it have been quite some while since I last wrote anything in NXC, I did this as a quick brush-up project.

Supports scrolling up and down with the left and right button on the NXT, and supports the control characters ‘\n’, ‘\t’, ‘\a’ and ‘\b’. ‘\b’ only works on the text you are currently adding though.

Since I’m not working actively on RICcreator in the moment, not much have happened the last few months, however I just rewrote some terrible code which was not safe. RICcreator would crash if the settings.xml file is formed differently than expected, so when a new version changed the format, it would crash if the old .xml file was kept.

XML handling

The XML parser previously used was rapidXML which promises great performance, and since I want to do some game related programming with XML I wanted to learn the API. However as I tried to use it with RICcreator I quickly realized it was rather tedious to work with. So I slacked on the implementation. Most importantly, I didn’t do any validation and simply chained the node lookups. So for example to get to the “settings” node in the “RICcreator” node I did this:

doc.first_node( "RICCreator" )->first_node( "settings" )

However if first_node() can’t find the node it returns NULL and in case of this the second call will try to dereference a NULL pointer and crash the application. To avoid this it should have been done like this:

This is quite some code for a simple lookup, so as said I slacked. Adding nodes to a new document (when saving the settings) was even more tedious as you had to allocate nodes and then add them. (On the other hand, I couldn’t slack here.)

So I have been looking for a simpler C++ XML parser and recently I heard about pugixml. I like the API much better, it is also a lightweight parser and apparently even faster than rapidXML so I tried it out. The previous lookup would look like this in pugixml:

doc.child( "RICCreator" ).child( "settings" )

This doesn’t share the problem rapidXML has, because child() returns a “NULL” object on failure. The NULL objects functions all return another NULL object, so you can chaining like this is completely safe as long as you check the final result.

So I have rewritten all XML handling to use pugixml now and I’m quite happy with the result. The code is a lot prettier and most importantly, it shouldn’t be able to crash like before.

Other changes

The dithering have been changed to use Filter Lite instead of Floyd-Steinberg, which produces nearly as good result but which is quite simpler (and therefore faster).

A fun addition is grayscale importing support. If you want to toy around with grayscale images on your NXT, RICcreator makes this easy by letting you import the same image several times with different thresholds in one step.

The Number opcode is now no longer aligned to multiples of 8, as this limitation has been removed in the enhanced firmware.

A few bugs have been fixed and it should be possible to compile in Visual Studio again. (I haven’t checked after rewriting the XML stuff though.)

The time has finally come where I ventured out in the myriad of paid hosting providers. Free hosting isn’t really worth it and WordPress.com doesn’t allow you to do anything (without paying buckets). WordPress.com is fine if you just want to have a blog, however as a CS student I want to mess with everything. So I tried a local hosting provider and we will see how this goes…

Status on RICcreator

I haven’t had the time to develop on this for quite some time but I can do some work on this regularly now. However I’m not going to do that. While far from perfect, RICcreator have matured and I do no longer feel the need to use nxtRICeditv2 anymore. I haven’t even started the program up in months as I’m using RICcreator for everything RIC related now.

As I’m not seeing people use it I will simply fix bugs and add features when I want the functionality. So while not dropped, development will be slow. I will still fix bugs if anyone reports them and I’m open for feature suggestions. I will do one more release which probably will be the last major update for a while.

While I want to move my focus to other things, RICcreator marks an important milestone for me: I am now creating software which I find useful enough to use in my everyday life. RICcreator is my first medium-sized application and I’m quite satisfied with the result.

What I have been doing the last few months

Superus

I was working on in a project group for a project for CS at university, however 4 out of 7 people in the group decided to drop out of CS. So the lone 3 remainders had to write 80 pages in 2 weeks, which worn me out a bit. Anyway, the project was about image editing and we wrote a couple C programs to do several functions. The code is made available at SourceForge as Superus.

It uses a command line interface and only accept PPM input/output so it might not be that useful for many, however it can read 16-bit PPM, edit it in 64-bit float and save it as 8/16-bit using dithering to ensure maximum quality. So it is possible to do certain things which simple isn’t currently possible in GIMP. (It should also be gamma-correct unless we screwed up on the conversions.)

I have written about half of the code, the parts which handle PPM input/output, image representation (how it is stored and worked with internally in the programs), scaling, brightness, blurring/sharpening and various filters. “nielssonnich” wrote the Command line interface and scripting code.

I might continue to do some experiments with this codebase, but it should be considered to be a one-shot project though. I might also write a post about one of the cases where I had to use Superus instead of GIMP to achieve the results I wanted.

BPM graphing

I wrote a small quick program to graph the BPM changes in a .sm chart for DDR rhythmic games which you can read more about here: BPM graphing [Thirdstyle]

I was in the process of porting it to PHP but I didn’t finish it. However I want to finish it soon as I have some bigger plans (see below) which I hopefully will start on in the summer vacation. It shouldn’t be more than 1-2 days work anyway…

What I’m doing now

I have started on a new project for CS with a new group and our goal is to create a spell checker which can correct grammatical errors in Danish. We have not yet decided whether we will try to parse sentences or try to make something like a neural network, but nevertheless this will be a challenging and interesting project.

Another thing I’m working on is a custom theme for this blog. Now that I’m not limited by WordPress.com I can write my own PHP code so I can achieve just want I want. I’m going to take my sweet time on this as it is low on my priority list.

LDraw viewer

At university we are taught C#, however the exercises are quite boring as we have to write some random code which does nothing more exciting than a “Hello, World!” program. So instead I will be working on a project I wanted to do for nearly a year now, a LDraw viewer. It should load a LDraw CAD model and display it on the screen using OpenGL for the graphics.

I’m obviously not trying to create something special here, as there are already several software out there which has similar functionality. This is purely a study project and in particular I want to get a good grip on OpenGL and 3D graphics. However since I also want to cooperate this into my education I will be writing it in C#, to get some proper experience in it. I haven’t written any code so far, but I will do so within a weeks time.

NXT RPG

You heard right, I haven’t forgotten about this project. It pains me that I have not completed the ‘level 2’ mode which contains the battles, so I want to do something about that. I might do a bit of work on it from time to time, but don’t expect sudden rapid development on it ; )

6wd Off-roader

I’m still not done with this project, however I’m almost finished now. Just missing a bit of reinforcing of the mechanics and improving my software and I will call it done, I want to move on after all.

What I will do in the future

DDR for keyboarders

One of the project ideas I have on my Projects plan page and I will attempt to start on it this summer. (This was why I did the BPM graphing thing.) I’m been playing Stepmania for 4-5 years now however I absolutely hate the engine. It is slow, buggy, old-fashioned and straightforward annoying. I want to try making an engine which is very different in a lot of points but which still keeps the good old game play.

This is a very ambitious project and I might not end up with anything useful. However I want to challenge myself even further and I want to tell the community that there are people out here that wants to move on from the old DDR arcade days.

This is definitely a large project and I have to make use of a lot of technologies and techniques I haven’t used on the PC before, only with NXT or PHP. OpenGL, threading, databases and perhaps even some driver interaction stuff.

Conclusion

There is really a lot of stuff I want to do and not really that much time. Can I pull all this off without going overdue? Probably not, but I will really want to try my hardest to arrange my time so I will complete everything. I tend to waste a lot of my time doing random stuff which is really a shame when there is so much I want to do.

Focus this time has been mostly on sprite creation/editing, with a few nice additions.

Polygon enhancements

The last missing piece in the drawing routine was fill_shape in PolyOut(), which has now been implemented. Here is an example:

Originally I planned on just using the code from the firmware however when I did so I noticed that the polygons didn’t look quite as good as I expected. The code which the firmware implementation was based on was both poorly implemented and flawed, so both the firmware and RICcreator ended up having the same issues.

So I spend some time on fixing up on those issues and modifying the algorithm to fix the flaws. This also means that the output isn’t exactly as on the NXT until is fixed there. I will write a full post about this later, when I’m done fixing a XOR issue with unfilled polygons which is also apparent in the firmware.

Sprite Editor

Sprites are no longer created at 100×64, you start out with an empty sprite like in nxtRICedit now. It is a minor thing but still rather important anyway.

I have also fixed up the scrollbars a bit. Still not perfect, but a lot better than before. A reset button has also been added in the corner.

Image importing

I have added a third way to convert images to 2 colors, Floyd–Steinberg dithering. While dithering in most cases look quite neat, it is not that useful when used on the NXT screen. The resolution is simply too small in most cases, making it difficult to see what it actually is. It does work well on some images occasionally, so experiment!

Dithering, Global thresholding and Adaptive thresholding now also takes gamma in account. Almost every image on the web is encoded in sRGB which defines power of a RGB value. 0 means black, 255 means completely white. The value for 50% black, 50% white however is ~187 and not 127. I might write a full post about this later.

Another enhancement is that adaptive thresholding have been greatly optimized. Actually, I just cache some results, however this meant that the complexity was reduced from O( n^2 ) to O( 2n ) where n is the size parameter. Before a size of 30 would be quite slow, now you can use 99 without even notice any slowdown.

RICcreator is a MDI application which is implemented by using tabs. Because tabs are used, only one document is viewed at a time.

Up to this point it was implemented using QTabWidget which provides tabs and a area on each tab to place widgets in. Using this, a editor (ricfile_widget) was created on each tab which each owned a ricfile.

When a user clicked on an action in the menus or toolbars, this action had to be routed to the editor currently shown. Since there are about 10-15 commands which deals with the ricfile, 10-15 wrapper functions had to exist in the MainWindow with 10-15 actual implantations in the editor. There were mainly two types of actions, open/save/export actions and actions which added a specific object.

The open/save/export actions are useful no matter which editor you are currently using, while the “add polygon” action is pretty useless when using an editor for modifying RIC fonts. (Not implemented) The goal was therefore to keep the implementations for open/save/export in MainWindow while removing all the other actions from MainWindow and keeping them strictly in ricfile_widget.

Design

Instead of having the QTabWidget manage the editor for us, we make MainWindow keep track of it instead. Secondly we change the ownership of ricfiles to the MainWindow. To do this we make a class which keep track of a ricfile which contains the information needed. The class (openRicfile) contains the following information:

The ricfile

The file source, was this created in the program, loaded from the HDD or downloaded from the NXT?

The ricfile editor which is used to edit this file.

The name of the file

The file edit state, has the file been changed since it was loaded?

Since MainWindow now owns the ricfile and the required information about it to save/export the file, the actions can now be directly implemented here.

To make it possible to create different editors, we create an interface between the MainWindow and editor. As open/save/export is now done by MainWindow and that every other command was editor specific the interface must not contain any of these. To still be able to have editor specific commands in MainWindow we allow the editor to create a Toolbar which the MainWindow will shown.

In return we add a requiriment to the editor, it must be able to change the active ricfile. The interface (ricfileEditor) have the following properties:

Change the ricfile to be edited by specifying a openRicfile.

Request a toolbar to be shown

Signal which tells MainWindow when openRicfile as been edited.

Implementation

Instead of using a QTabWidget, a QTabBar is used instead. QTabBar only shows the tabs, it does not create a space to hold widgets. However we get slightly more control over the tabs appearance. But now that an editor can change file, we only need one for each type and therefore not a separate space.

In openRicfile we therefore only save the editor type for each file. So openRicfile instead keeps an list of implemented editors. When we request a editor, it will return the editor specified by the openRicfile. (Editors will only be created on request to preserve resources.) But since there is only one editor, we will need to store information about how the file was viewed in the editor, as this is lost when changing file. I still need to implement this, but it will just be an extra field in openRicfile containing the required information.

All the “Add [object]” actions have been implemented as a Toolbar in ricfile_widget, so MainWindow is now completely free of them, it just changes the shown toolbar whenever a new editor is to be shown.

Results

MainWindow and ricfile_widget is now much cleaner implemented as it doesn’t contain functions which is half implemented in MainWindow and half implemented in ricfile_widget.

Secondly it is now possible add new editors quite easily and there is an way of adding actions to be shown in the MainWindow.

A side effect is that memory use has dropped greatly. ricfile_widget used about 600KB of RAM, so after opening 10 files you had doubled the memory use of the program. Now it only increases with a few KB for each file. (This is an empty file however, haven’t quite tested it with large files, but it shouldn’t be too much nevertheless.)

Another side effect is that since QTabBar is now used, it is possible to specify the text color of each tab individually. So a file which have been edited and not saved yet is highlighted by changing the color to red and adding an asterisk to the end:

Download

Not much have happened on the SVN repository, this is the pain of not having an Internet connection and not being able to do local commits with SVN…

Overview:

Offset added in nxtCanvas

VarMaps and Polygons

Command line improvements

Adaptive thresholding

Loading RIC files from a byte stream

Download

Offset added in nxtCanvas

A huge update has been made to nxtCanvas which emulates the NXT screen. And offset to the drawing commands have been added, so instead of always assuming the lower left corner to be (0,0) it can be anywhere on the canvas.

It is not intended to be changed manually however. The reason for adding this is because you get some ugly side effects when automatic resizing of the canvas is turned on. If you use PointOut(-1,-1) with automatic resizing turned on, the canvas is expanded and the point is drawn at (0,0). However if you do this a second time, PointOut(-1,-1) will point to another pixel than the previous call which might not be desireable.

However a more serious issue was in the editing GUI for nxtCanvas. If you for example tries to draw a line it shows a preview before actually drawing it. When you move the cursor outside the canvas it automatically resizes. However if you moved the cursor to a negative coordinate it would still keep the canvas in the same place. If you tried to draw a line to (-10,-10) this command might have been issued 5-10 times because of the live preview, causing the canvas to be rapidly expanded. Because of this the live preview has until now had automatic resizing turned off, only turning it on just before the user stopped drawing.

While this is finally working as intended now, adding that offset was a pain since it caused pretty much everything drawing related to break.

VarMaps and Polygons

VarMaps have been implemented for a long time, however it didn’t have an editable GUI. And since this is one of the most important elements, RICcreator have been pretty much useless so far. The reason that I didn’t add it until now was that I was not satisfied with the way it is implemented in nxtRICeditv2 and wanted to do this differently. However I didn’t get any ideas on how to improve it so in the end I just implemented a similar design.

VarMaps and Polygons have been implemented using the same datatype in RICcreator, so the GUI for them both is the same.

With this done, RICcreator now supports editing every RIC opcode in the enhanced firmware. Only thing lacking now is implementing fill_shape for polygon and the special copy options for RIC fonts.

Command line improvements

RICcreator supported one parameter, a filepath to a RIC file to open. You can now open several files at a time by specifying more than one filepath.

A completely new addition is converting files through the command line. By using the “-convert” parameter you can convert RIC files to PNG. It is used like this:

RICcreator -convert FROM_FORMAT TO_FORMAT filepath

If you want to convert “circles.ric” to png you use it like this:

RICcreator -convert RIC PNG circles.ric

This will create “circles.ric.png” in the same folder as “circles.ric”.

Formats are:

RIC: ricfile, can be used for both input and output

PNG: PNG image, only output

C: C header file, only output

RICScript will be added when implemented. Currently conversion is done with all RIC parameters set to 0, if anyone have a good idea to how these could written on the command line speak up!

A note on the PNG export using the command line is that the nxtCanvas is set to 0x0 and then every draw command resizes the canvas to fit everything. So the resulting PNG will not be 100×64, it will be sized to contain everything drawn and the (0,0) point.

Adaptive thresholding

Thanks to the material Linus from Mindboards gave me I have now implemented adaptive thresholding in the import image dialog. I have written the algorithm myself so it is a bit slow right now.

The improvement with using adaptive thresholding instead of global ranges from almost nothing to quite a bit. However it is more difficult to get good results with it so for now global thresholding is default.

Global thresholding to the left, adaptive thresholding to the right

Loading RIC files from a byte stream

It is now possible to load a RIC file from an array internally. This makes RIC loading much more flexible. I cover this more deeply in another post though. The most noticeable change this made for RICcreator is that the default RIC font is now embedded into the program and that it is possible to convert the file into a C header.

Download

riclib have until now read RIC files directly from a file stream. This is done using a distributed approach, each nxtVariable is passed a file stream pointer and loads the data it needs by itself.

A ricfile in riclib is made up by an array of ricObjects which each contains a list of nxtVariables containing the data. When a ricfile starts loading, it reads the first 4 bytes which contains the ricObject header and creates the ricObject which have the same opcode as specified in the header. That ricObject read funciton is then called, loading each of the nxtVariables it has. The whole process is then repeated untill it is not possible to read another header.

Adding a second source to read from would require an extra read command to be added for each nxtVariable which would be a lot of work.

A file can easily be converted into a char array, so I could just drop direct file reading and rewrite every function to read from a char array instead. Actually, I should have done this from the start. (I didn’t because this would require 3 paramters to be passed each time, the char pointer, the current position in the array and the total lenght of the array.)

I decided of some reason to do a more complicated approach. I added a abstract base class nxtIO which is used by nxtVariable to read and write to RIC files. I have then added to classes which inherits nxtIO, nxtFile which implements file IO and nxtStream which implements IO on a char array. The advantages of doing it like this is that I only need to pass one parameter, the nxtIO pointer, and that it is possible to add several other types of IO without redoing the reading functions in nxtVariable. The disadvantage is that it is more work and that I probably will not need to be able to read/write from anything else than char arrays anyway…

The reason behind using byte streams

One of the key goals with riclib and the reason it is keept seperate from the GUI code is that it should be easy to use it to extend other applications to use RIC files. However since it needed a RIC file containing the font to use with TextOut to be located together with the exe this could complicate matters for the application developer.

So one of the key benifits with reading from a byte stream is that a RIC file can be embedded into the exe. IO to a byte stream can be used in the other direction too, in order to create a C header file containing a RIC file to easily embed the RIC file into C/C++/NXC programs. (quick implementation done)

Another important reason is that when you use riclib in other applications you might not be able to read/write directly from/to a file. Consider that you want to upload and download RIC files to the NXT. The interface functions will undoubtly use byte streams instead of files. (I will add this feature as soon I as can figure out how to do it.)

Another case would be using riclib together with the Windows Shell. Once I figure out how to create a COM module I’m planning to add RIC support into Windows Explorer. While supported, Microsoft discourages using filepaths and suggests accepting and using bytestreams instead.

Example

I’m currently creating an image viewer using QT. QT already supports most image formats like JPG, PNG, BMP, SVG and more, but allows you to create plugins to implement special fileformats. So I created a plugin to extend QT to support ricfiles using riclib. This will not just extend my application, but every QT application using QT’s inbuilt image functions. (The application and plugin will be posted in the near future.)

I will not go into depth about how this is done however one of the key aspects is that QT is not using filepaths, but its own QIODevice class which does a similar task as my nxtIO class. I could create a sub-class which inheriths nxtIO and read/writes to a QIODevice, but I took the easy solution and just used the QIODevice to read the whole file in one go and use nxtStream instead.

The canvas is created at size 0x0 with auto_resize on. The RIC file then draws on the canvas, expanding it as needed.

The next step is to convert the nxtCanvas into an image format the application supports which is normally rather trivial. One thing to remember is that (0,0) is located in the lower left corner in nxtCanvas where it is most often located in the upper left corner in other formats.

A great trip to Ireland has ended, a trip without my computers, music and anime. However not being completely able to detach myself from everyday life I found some paper and a pen and compiled a list of features I want to add in RICcreator.

So while not complete and subject to change, here is the most important features to be done:

Features to be done before Alpha release:

VarMaps must be editable. I cannot drag this out any longer, so I will go with an interface similar to what is found in nxtRICedit. The entries will use the left part of the screen, with the graphical view on the right. (Graphical view will automatically swap x-y axis depending on the available screen area.) Graphical view might first be added in Beta though.

Polygon will also be added in a similar way as VarMaps, just with a different graphical view.

RICScript import/export support.

Export an open file as a C/NXC header file.

Support parsing a RIC file from a byte stream internally. This will improve Windows Shell integration and will make it easy to include GraphicArrayOut() in nxtCanvas.

Embed default font in EXE instead of require it to be located in the folder. When the two previous features are added, this will be a piece of cake.

Improve command-line interface. Support opening several files at once and make it possible to convert files from one format to another.

Simple/beginner mode which just shows a nxtCanvasWidget and then manages the Sprite and Copybits element in the background.

RIC font edit mode to simplify RIC font creation.

Remember recently opened files.

Check for updates. (Automatic vs. manually?)

Remember RIC parameters.

Upload and Download RIC files directly to the NXT.

Any suggestions are welcome.

I have added Trac to the SourceForge project page which I intend to use as a bug tracker instead. The reason for this is because in includes a nice Roadmap page where you can add Milestones. I will try to issue tickets for the features which needs to be done and bugs which needs to be fixed and then add them to the Milestones. It should work as a good TODO list if I remember to use it. I will properly close the old bug tracker when I add a few more tickets to Trac.

An old project of mine, from before I got my NXT 2.0 kit. From about 2.5 years ago iirc.

Old description from HDD:

A robot which can write on a computer by pressing the keys on the keyboard.

My original goals

To become more used to make building instructions.
Making it to work on multiple keyboards so it isn’t specific for a single keyboard/working condition.

Making programs that can be modified easily to perform similar tasks.

Making simple and strong constructions.

Never made building instructions…

Should work on multiple keyboard, but remains untested…

Program works by using coordinates, nothing like the “modifiable” program I wanted…

Most of the construction was simple enough though.

Program

The program was made in NQC since it would most likely fail in RIS…

By using the rotation sensors, the motors worked like servos changing speed/precision depending on distance.

Keys were found by using manual entered coordinates…

By using some functions in Windows which are normally for people which have trouble using the keyboard, you can activate a function to press keyboard shortcuts one key at a time. This can be done with shift and uppercase letters so caps lock isn’t needed and furthermore it could be used to control many Windows features directly from the keyboard.

Still, I didn’t continue that far…

Construction

The frame was made simple, long, and strong. The long beams are made of both studded and studless bricks to reinforce each other. So even if the span is over 30 cm, they don’t bend that much.

Wheels are used instead of gearracks on the frame and this works okay…