Motorized Revell Babylon 5

[Pixelworks]

Love the project and look forward to WIP photos.... I used a vertical slip-ring (rotary joint) in my B-9 build for the torso and it has stood up just fine for all these years. I used a 12 wire version, it takes the power from the battery in the legs and for the two motors for the tracks up to the main body and has not given the old boy any problems....

Hey Teslabe,
thanks for stopping by. That B9 of yours is looking really good. Yes, I also looked around for the same type of slipring that you have, unfortunately, because everything needs to revolve around a horizontal rod, I need a hollow version that will fit the support rod (in my case a M10 hollow lamp rod), which I will be using to route the wires into the habitat section from outside.

Normal vs. Hollow

Problem is that I could not find any with a large enough hollow diameter (and yet fit the inner diameter of the habitat section of B5) and anyway all of the hollow sliprings that I found, did not have enough cables going through the slipring... I think 6 cables was the max.

Which is why I finally decided to construct my own. Of course it will not be anything fancy, but I will print out resin modules on my 3D printer and will slip a slice of copper tubing onto it for the connectivity.

The copper tubing will fit around the smaller round part and the cutout notch is where the power/signal cable will be soldered to the inside of the copper ring. The idea is that they are module and a second part locks in place to the next, meaning I can make as many slipring channels as I have place for inside the model. I have already done a couple test prints, in principle everything works as expected, but the first ones were too bulky and the fit was not as snug as I wanted... but I am on the right path.

In the end it will look and function similar to the slipring below:

And, just so that my thread is not completely filled with theoretical drawings and images stolen from google, here are the last prints of the slipring with the habitat section for scale. I would still like to make it a bit more thinner to take up as little space as possible but you get the idea. The thinner piece is meant to be an endcap on the last ring. If you zoom in, you can see the depression where the rings all mechanically lock into one another. Of course they will be glued, but I did not want to rely on glue alone against any torque.

 

[Pixelworks]

Good choice going with a stepper motor, I've used them for years in many of my builds, just be very careful of the heat, stepper motors run very hot,
by using the 4988 stepper motor driver, good choice, you can easily control the current (heat) to the motor with the small trim-pot on the board, start low and bring the current up slow and check the motor's temperature, it may take a while due to the motors mass so take your time, I also added small "dip-switches" to my boards to easily select step and direction. If I may ask, are you bread-boarding the ATmega328P to keep things small? If so a Pro-Mini should work for your motor controller, you will need a FTDI board to flash it but it comes off when your done and can be bought for under $3.00, if you don't mind paying a bit more there are Arduino boards with built-in USB ports, I've used two smaller boards for some projects, hope this helps, unless you already knew this, then I'll back off....

Yes regarding the heat, I have my worries. In my favor, the actual turning will be very slow so I can turn down the consumption to a bare minimum. But still, as you mentioned it is one of the few downsides to Steppers. Once I have the stepper programmed how I want it, I plan on letting it run in a similar enclosed environment for a couple days straight to see what kind of temperatures can be expected.

Regarding the ATmega328, yes. Although there is actually quite a bit of space in the habitat section, everything is revolving around the central rod, so the height and width restrictions are really only the half of the cylindrical space and are a bit cramped. But aside from that, I simply got into the habit of doing it that way quite some time ago and I suppose even if I could fit a nano or pro mini into a model I would probably still go with the breadboarded version. I have never measured it, so it is likely purely subjectivity on my part, but by removing everything else the chip doesn't need, there "should" be a reduction of workload and therefore likewise in heat and power consumption. Which in enclosed spaces or with battery power, could (again theoretically) make a difference.

In the end, it may really just boil down to the fact that it is only my way of "getting my hands dirty"

 

[Pixelworks]

Just a short addition:

I will be using the AccelStepper library for Arduino to control the stepper and LEDs. It is an updated version of the standard Arduino stepper library, and is very easy to use, in addition it is great if you are using multiple steppers simultaneously (which of course I am not planning on doing here) but the same applies if other operations are to be done parallel.

Forgive me for going on a programming tangent here, but the most basic part in just about any arduino code is to avoid using the function Delay(). To explain, in order to "control" the speed of a stepper within the programming you tell it to take a step, wait an instant and then take the next step. Now this "waiting" is in such a small timespan that the human eye does not perceive anything other than a continual movement. The problem is how to declare such a waiting period. There are basically two methods to do this... Delay(), which is the simplest way, causes problems if you are doing anything else in your code because it literally tells the microcontroller to stop doing everything until the wait period is over, which in turn delays everything else in your code (e.g. LED blinking) in the same manner and causes everything to get out of sync or worse.

The other method is to use Millis(), which is easy to understand but somewhat more complex to implement, requiring multiple lines of code. With Millis(), you basically tell the microcontroller to check its internal clock (which simply counts the milliseconds from the instant it turns on), and you use that as a basis to stop and start depending on if the current millisecond count is higher than a set limit and then raising that limit for each next iteration. The huge benefit of doing it this way is that the microcontroller is allowed to do other things while it is checking if the millisecond limit is reached or not.

This same concept applies to the blinking of LEDs as well, meaning the process of turn LED ON, wait, turn LED OFF, wait, and so on, the "wait" portion needs to be done with Millis() and not Delay(). Unless of course you are only blinking one LED with no other operations, then you can get away with using the delay option and no bad side effects.

 

[Pixelworks]

Lighting Concept

After much thought here is the placement of various LEDs or Fiberoptic outlets:

The yellow blocks are meant to be observation windows and will be many small dots representing small windows on multiple floors.
The red blocks are the entrances to the hanger bays
There are typical "Enterprise" navigation lights (Perspective Driver's Seat: Red = Right & Green = Left) on the front fork and the solar radiator arms.
The red triangles are indirect illumination under the various hanging parts. The idea is so that small vessels know not to fly through the open areas.
The blue triangles are just illumination for the Solar radiators, as a type of secondary warning (and I think it will just look cool ).
The Solar Radiators also have red tips as an extremity warning. (I am leaving these constant on, but a blinking patter might work here too)

Here is a close up of the main docking bay entrance, which is for the most part correct with what is seen in the series:

 

[Pixelworks]

Texture Concept

I mentioned above that I wanted to add slight texture to the station that are never really seen and although the decals imply slight differences, I do not consider them to be screen accurate. The height or depth differences will not be more than a millimeter so just barely noticeable, but anything more would certainly bust the scale.

The biggest difficulty with the trenches (the dark fat lines) will be making sure they match up with the same "implication" on the decals.

If you compare the texture with the lighting you see that some of the "windows" are only possible due to the higher areas.

 

[Pixelworks]

I just found this image of the B5 station on The Wertzone. I am not sure where it is from originally, I am guessing it is fan-art so not likely cannon. Like almost all other pictures of Babylon 5, everything is dark and extremely shadowed, making it really hard to see everything. Batman would really feel at home here.

Interestingly, the picture does show some of the texturing that I am aiming for. It also depicts more lighting as what I ever saw in the series, but still many parallels to what I have in mind... all in all this very close to where I would like to go.

 

[Millenniumf]

I don't know what technique you're planning to use for the paneling, but if it were me I'd employ REL's technique, which is to lay down masking tape in the hull paneling patterns, then spray filler primer over them till a thick coat has been built up, and then peel up the masking tape.