Building the Thor robot

Took a lot of soldering buy all 7 motor connectors are now being soldered and connected to the motherboard.

The connector at the right bottom is intended to provide 5V and 12V to the Thor robot to power additional electronics and power the cooling fans.

On the left bottom I also provided a spare opening for a DB9 serial cable for additional communication for sensors inside the robot.

Life gets easier for testing every motor independently during software development but also when it becomes part of the robot.

The only missing part is the Nextion display that I reordered after damaging it with a reverse polarity.

Yesterday by accident I reversed the polarity of the +5V with the ground and I saw a flash. This capacitor blew up

The capacitor is a 10µF, I tried to repair it but the display does not start up anymore not even when I try to upload new firmware. There is no other visual damage to be seen.

I just ordered a new one to replace it.

The rest of the electronics is still in good shape.

One year of standstill on the Thor project development because of other priorities in my life. But I have holidays so I continue where I left off.

The focus is on the electronics, now and since I had many sparks in my open test setup, it was time to contain it into an big box.

The idea was the biggest box my printer could print 210x190 so I have space to change the internal electronics. The box consists of 3 different parts so I can alter them at will.

For the controller I use 24V, but my cooling fans will be 12V and I also need 5V for the touch screen that draws a lot of current.

So I decided to have 2 step down converters, one for 12V and one for 5V.  One additional 5V to 3.3V may be needed in the future but right now the mother board may give enough power.

The side panels is printed as a separate 3d print. Again to play with different configurations.

I have a forced airflow using a silent ventilator to cool down the parts. Including the touch panel that also can become pretty warm. The ventilator is a Noctua 12V ventilator, because I tend to work at nights and the neighborhoods wants to sleep. The one in the one in the picture is 40x40x20  and only temporary. I had it laying around.

The connectors at the top row are 7. One for each stepper motor. The intention is that I can pull each stepper-motor for testing. This way I can systematically test the software without the stepper motor to do real movements.

One additional connector to provide 12V and 5V to the robot as additional supply. Could be used for the fans or additional electronics.

The touch panel is at this moment mounted in a flat panel. For this setup this is enough, but could be reused as a  disconnected panel later in the design.  I already provided a RS232 opening in the side panels.

View with the sidewall in place.

Connector left is the incoming 24V from the external power supply.

Completed top view.

The holes at the front are for the network connector and the 2 USB connectors.

Side view to show the connectors and also the power switch on the box. That power switch cuts off the incoming 24V, so the motor drops out instantly.

Having a switch at the 220V mains does not act fast enough to cut the motor power. I need instant shut off-during development of the software.

Started to print the Thor upper part I have found created by Sepio: https://hackaday.io/project/26341-building-and-improving-the-thor-robot-arm/log/70087-day-18-redesign-of-art3-and-art4

I needed to reprint the part because I need cooling, and it is a great way to test NGEN how it performs with bigger objects.

I like Sepio's upper part, it looks easier to assemble and has a fan included to cool the upper part.

The Art 3 lower body. 0.3 mm layer heights, Simplify3D estimated this a 7H job but it turned out to be 8H45. You can see the support structures that actually came off very easily.

Inner part of Art 3 lower body.

The day before I tested 3 different materials I received on Friday.

I started with the part that guaranteed failed every single time I used ABS.

• Black = ColorFabb_HT (€ 45/700 gr,)
• Red = ColorFabb_XT (€ 40/700 gr)
• White = ColroFabb NGEN (€ 35/700 gr)

All 3 jobs are 2 hours printing.

Top parts

Bottom parts

That test concluded me to go for NGEN when I print parts for Thor.

Not directly related to the Thor project but I know that some people are interested.

I have an Original Prusa MK2 (MK2/S upgraded now)

I always had big issues with warping when I use ABS (ICE) filament when printing the Thor robot.

Here are some samples with different materials.

Top is my Movidius Raspberry Pi 3 with camera intended to experiment with Neural networks.

Bottom left is a Apollo 15 landing site I used as an experiment to testprint my Original prusa i3 MK2/S upgrade. I originally used 2 top layers which worked great with ABS but with NGEN it definitely needs 4 top layers.

Detail part of the Apollo 15 landing site. Layer height is 0.2 mm NGEN, and I did notice these dark spots I cannot explain. I never saw them when using ABS or PETG.

Parts that I printed for the MK2 to MK2/S upgrade of my printer. I did not install them yet.

The top part right is a test print  with ABS (ICE) because I was wondering if the printer upgrade made thee ABS print better, but I still had the warping issue. However the red ABS (also ICE) made a perfect print.

Also you don't see these mysterious dark spots I had with NGEN.

Test of ART1BOT this time printed in NGEN filament.

It printed without any hiccups on my 3D printer nor warping. It feels very solid and the details are pretty good.

Detail of the cogs 

The rim is almost not bendable, and will splinter when pressed to hard.

Bottom part (actually this is the upper part in the Thor robot). You can see that support structures left some fragments behind. The object does have sharp edges, something I did no have when using ABS. But these sharp edges are easier to get rid of wit sand paper. Easier than ABS.

Because the Thor robot has multiple long duration 3D prints I tried to reduce the noise of the printer because some prints goes into the night. I don't think my neighbors can hear it but I prefer to prevent it is I can.

So  upgraded my Original Prusa MK2 with a Noctua fan that needs an adapter.

The adapter I used is : https://www.thingiverse.com/thing:2076234

The fan used is http://noctua.at/en/nf-a4x20-pwm

The NF-A4x20 is 20 mm thick and I paid 14 euros.  It is really that silent.

You also see that on the right I have a 3D printed fan cover that I can control the air flow with by adding or removing tape (even during printing). The fan itself caused in many cases a Termal Runnaway and ruined the print.

Last time I tried PETG, which is more flexible than ABS but also more droopy. The filament support structures are hard to remove.

Danny pointed me to ColorFabb NGEN, more expensive but I gave it a try.

http://www.omd3d.com/omd3deshop/co-polyesters/63-ngen.html

(Remark, the site seems to have a bug in its javascript. You have to press the browser refresh page every time you selected something in Firefox)

(Assembled cable train)
First print was parts to have a cable train.
With ABS they all came lose of the bed during printing. But with NGEN they did stick and the print worked out nicely. I printed at standard 2400 mm/min and even 4200 mm/min. 

The first things you notice is that the NGEN plastic is as hard as PLA. So far it seems not to break as fast as PLA, but it does break when you bend it too far. 

Detail of the cable train.

I had to break of the left part (ART1BOT) printing job because it was well into the night and it took longer than what Simplify3D predicted (I think the Prusa printer moved slower than 4200 mm/min)

I am redoing this job at this moment since this part had a sensitive thin wall part that easily broke off in ABS.

I tried to print this part with CarbonFil but my printer stuck its head several times on the parts and I got an offset error and a failed print. I think this NGEN can do the same thing as the CarbonFil. 

Last week I decided to restart the Thor software design, this time built up to be more professional. With Professional I mean, adding comments, structured naming conventions, prepare it for full blown professional design.

As I was commenting the code I ended up at my Debug LED part and started to wonder about debugging the software.

The initial design was actually programmed for an Arduino Nano. I did not have a logic analyzer yet and I wanted to test the concepts of the interrupt based pulses. I used the Debug LED to visually see if the code actually worked. I could slow the step motor pulse to any speed I wanted even step per step.

The Arduino Nano is so easy to hook up to your PC, no wiring, no real mechanical parts and it forced you to develop code wiring an even more constraint space.

I can only conclude that it had to be some compiler bug. Rewriting my code made it goes away. But that blinking LED was vital for finding a workable solution.

The Debug LED was of no more use... or so I thought....

This single tiny LED is always on the Arduino controller, it never fails and can give vital feedback of the state of the software even if there is no display connected to it!

It can display the initialization stage, it can display the diagnostic stage, it can display the running stage... Just by blinking.

The key to all this is how you blink.

Ideas are:

• Initialization stage: blink when it goes to the next stage. Since every initialization stage will be different in duration, the debug LED pattern will flash in a predictable pattern.
• Running could be a regular repetitive blinking.
• Critical error could be a fast blinking state, or all on or off when the software crashed.
• Starting an operation could be a 1 second LED on followed by a second off as a warning that something is happening.
• Short blinks could indicate a command received from the display.
• Repetitive morse code could tell you an error code.

All this means is that my debug LED code will be extended dramatically.

Restarting the Thor software project from scratch. This time with the intention to make it publishable over time.

The software will be built from the ground up, not relying on libraries. The whole point of all this is to learn to develop robotics code from scratch.

It is written in C++ (Visual Studio 2015) with a plugin called Visual Micro that compiles the C++ code to the Arduino Due.

I already have the these parts described in my blog posts:

• Arduino Duo - Ultratronics v1.0 pro port mapping to the correct stepper motors.
• Enable, direction and stepper driver control with the purpose to move 7 motors simultaneously per step.
• Interrupt driven timer that works on the Arduino Due (this is different than an Arduino Uno/Mega)
• Nextion button press reaction to be modified in a more elegant design needed for the Thor control.

For me this is my little private project. I prefer to keep developing this at my own pace and on my own. I already work in teams professionally, this one I want to call my own. :-)

The Nextion HMI display library is good but for my Thor implementation too generic and not good enough for lots of controls, speed and reliability.

So I have chosen to redesign the library so in the end I have a more compact code and optimal (communication) for the Thor robot.

This code will evolve as it is being designed.

First the Nextion HMI editor project

We are designing a screen that have 7 enable buttons and beneath these buttons we have 2 rotation buttons. The original Nextion library code would have too many callbacks and hacks for what I have in mind.

I want to make sure that the connection Thor - Nextion HMI display is being monitored and that the Thor main controller can detect a HMI display that is giving wrong commands or unresponsive.

I also want the Thor robot controller library to be created more intelligently.

This screen show that for Page 1, we have a dual state button that will be programmed to enable and disable the rotating buttons below if it si active or not. This code demonstrates that we copy the bitmap under bitmap 2/3 (green/red active button) or 1 (disabled button)

This code runs on the HMI display only and does not burden the  Thor robot controller with too much communication.

The button has the "Send Component ID"  checked for both the Touch Press event and the Touch Release event. This will send a serial command to the Thor controller when pressed and depressed.

(If you look at this example, I have shortened the names and there is a reason for this. When I read in properties for this control from the Thor robot controller, the complete name is being transmitted which means longer transmission times and responses.

The button "Send Component ID" is seen below

The "Send Component ID" is a start byte indicating that we have a "Button" command, then followed with a page ID, the Control ID and a value 0 if it is depressed or 1 if it is pressed. It completes with 2x255 bytes marking the end of a command.

No properties of that control is being transmitted, that is not part of the current code I want to redesign yet.

This primary goal is to send make the Thor robot step the motor in a left or right direction and immediately stops when I release the button.

The Nextion Library has a call back method that you attach to a Pop (release button) and Push (press button) event.  I want to have only one callback for starting.

Which is defined below:

typedef void(*TouchEventButton)(byte page, byte button, byte pressed);

 The callback should be used as in example below:

void ButtonPress_Callback(byte page, byte button, byte pressed) {
	if (page == 1) {
                // Check on button MR_E0L (Motor Rotate E0 channel Left direction)
		if (button == MR_E0L) {
                        // I always check on value 0, only 0 = false anything else is true
			if (pressed != 0) {
				digitalWrite(LED_BUILTIN, HIGH);
			}
			else {
				digitalWrite(LED_BUILTIN, LOW);
			}
		}
	}
} 

This callback can now be much easier to extend, but also used as a very basic.

The callback should be processed in the Arduino Loop() method.

void loop() {
	// process incoming Nextion button presses
	display_loop(ButtonPress_Callback);
}

Initialization is done like this:

Choose the COM1 channel (you have Serial, Serial1, Serial 2, Serial 3)

#define nexSerial Serial1

Initialize the display, and set it to page "0"

bool display_init(void) {
	nexSerial.begin(9600);
	displaySendCommand("");
	displaySendCommand("bkcmd=1");
	bool ret1 = displayRetCommandFinished(1000);
	displaySendCommand("page 0");
	bool ret2 = displayRetCommandFinished(1000);
	return ret1 && ret2;
}

void displaySendCommand(const char* cmd) {
	clear_buffer();
	// Send command 
	nexSerial.print(cmd);
	nexSerial.write(0xFF);
	nexSerial.write(0xFF);
	nexSerial.write(0xFF);
}

void clear_buffer() {
	// Clear buffer
	while (nexSerial.available()) {
		nexSerial.read();
	}
}

The functional code to listen to a button command and call the command is specified as this:

(Remark: this code is still in development but functional! )

void process_button_press(TouchEventButton button_press_call_back) {
	static uint8_t __buffer[6];
	// Read next 6 bytes 
	if (nexSerial.available() >= 6) {
		for (auto i = 0; i < 6; i++) {
			__buffer[i] = nexSerial.read();
		}
		if (0xFF == __buffer[3] && 0xFF == __buffer[4] && 0xFF == __buffer[5]) {
			// Page, button ID, button pressed state
			button_press_call_back(__buffer[0], __buffer[1], __buffer[2]);
		}
	}
}
void display_loop(TouchEventButton callBack) {
	while (nexSerial.available() > 0) {
		delay(10);
		const uint8_t c = nexSerial.read();
                // Listen to button press and release commands
		if (c == NEX_RET_EVENT_TOUCH_HEAD)	{
			process_button_press(callBack);
		}
	}
}
 

 Note the test on ending 3x255 byte values.