CORE2+ROS Dead

The default software template provided in Husarion extension for Visual Studio Code doesn’t contain support for Web UI in cloud.husarion.com - we created offline tools because CORE2 can be used without cloud.husarion.com as well.

If you want to use ROS, a good place to start is this tutorial: https://husarion.com/core2/tutorials/ros-tutorials/1-ros-introduction/ .

Unfortunately I powered it off to re-arrange my power supply cable and now I am back where I started this morning. The config - or something - did not survive the reboot. Am I going to have to start from scratch every time I power off?

Configuration is only a one time process. If you have your CORE2 connected to the cloud, everytime you will power it on, it will be online and ready to use from cloud.husarion.com .

You will have to make this configuration process once more only if you want to connect your CORE2 to another Wi-Fi network.

I guess I am not being very clear. The board is doing NOTHING. Even shorting the hCfg button does not make it enter the configuration mode. I’ve already invested 20+ hours just to get it connected twice. Every time it powers off, I have to start all over again, with new errors. A faulty switch in a brand new board is bad enough.

How can I connect with a serial cable to try and debug this? I suppose I can yank the ASUS board off, but I wanted a robotics board. At this point I don’t care if I can use the Husarion cloud - I just want to ssh or remote terminal and get on with learning ROS.

Please help me get this board working or send me a replacement.

I can confirm, experiencing a seemingly identical failure as yourself, that connecting the CORE2ROS to your computer, you can re-flash it using Visual Studio Code.

However, I can also confirm that rebooting the board when it is configured to use the Husarion Cloud IDE brings back the issue you’re experiencing now. I haven’t tried a reboot when it is only configured for offline development through VSC, so I can’t confirm one way or another there.

My guess is that what we’re seeing is a combination of a batch of bad buttons (simple enough to repair, either with a hack like mine, or a new SMD button like what is there on the board as designed), and some buggy software. We’re early supporters. We signed up for hardware and software that may have some bugs, but these seem pretty minor problems in the grand scheme of things. I would be more surprised if we don’t see a solution going forward.

Thanks Michael. I appreciate the time, and agree that my childish lack of patience is probably not warranted. The board seems so promising - I just want to get moving! I was able to flash what I thought was just a small test program using VSC - based on company suggestion to you to confirm that the CORE2 board was alive. Do you mean I can re-flash the whole O/S this way? I would be quite happy to work without the cloud and be able to ssh to the ASUS board and start working with ROS there.

If this is possible, can I ask you for some basic instructions on how to use VSC to reload the O/S and then connect to the board? I won’t mess with the Cloud stuff for now. And will I have to short the hCfg for this?

Thanks.

What the basic flashing tutorial has you do is load some basic firmware onto the board. There is no ‘OS’ in the sense you and I are used to using, or even like what the Tinker board attached to it is running. The CORE2 just runs firmware that the user designs for it. Or, this is what seems to be the case with the example code I have seen. There is probably some Husarion-written software that sits even ‘closer to metal’ than the code that the user writes for the CORE2 that is rarely (if ever changed), something like VHDL, machine code, or even raw binary data, something sitting on some ROM somewhere. This is speculation on my part, mostly.

But if you are able to perform the basic tutorial flashing of your board, then your board works. It pretty much eliminates most hardware faults. There could still be a hardware explanation, but it being a software fault is far more likely. This means it will be up to the Husarion team to identify the failure and design a solution. This might take some time.

I would try writing some of your own code and see if you have any luck flashing it - see if it needs to be re-flashed after each reboot. Since it seems to center around LEDs, that is where I am going to focus with my software troubleshooting.

For USB connected programming using Visual Studio Code, are you using the image “Stable V1.0.0 CORE2ROS” Image or “Stable 1.4.4 hFramework - Husarion SDK for Hardware”?

You need both. Kinda. You need the image, you don’t need the SDK and should use the Husarion extension installed through Visual Studio Code - the SDK is overkill for just starting out.

Asus Tinker Board

Stable v 1.0.0 from Downloads | Husarion

CORE2-ROS

Visual Studio Code with the Husarion extension in the default configuration, plus updated USB drivers for the CORE2-ROS, both installed by following this video:


It seems like you only need to pull out the SDK if you are trying to develop for the CORE2-ROS on a system where you either can’t or don’t want to use Visual Studio Code (oddball Linux and Unix flavors, and other ‘geeky’ OSes that may not play nice with the Visual Studio Code for various reasons). Using the SDK is like driving a 4-on-the-floor transmission, compared to the automatic transmission that is in Visual Studio Code.

OK, I’ve been down that path, but VSC was moaning about “Please update your include path” and ‘cannot open source file “functional” (dependency of “hFramework.h”)’ so I went hunting. It flashes to the board and runs the program. I’m using a Mac, so some of the windows instructions don’t match; I also have an Ubuntu box here I can use.

What I’m still not getting is how I can get from here to being able to ssh or remote terminal into something that looks like Linux where I can run ROS things. Or how to get the wireless stack on the ASUS running so it is connected to WiFi. That;s why I was fixated on the cloud boot thing - it was on-line, if only briefly.

Thanks again.

Update: I used the tiny LED blink program and uploaded via VSC. It worked. I was hunting for code to try and do more and get at the ASUS in some way. Just before calling it quits for the night, I saw the blue LED was on. So I went to the cloud site and found the device was on-line, and I was able to connect. Using the “SSH Terminal” option under “More”, I actually got into linux land. I quickly did some usual Linux start-up things: apt-get update/upgrade, installed ntpd and started it, etc.

So this is good progress. But for some strange reason I cannot ssh to the system on the local network from my laptop. I messed with usual Ubuntu stuff, found no UFW installed, enabled passwords in ssh.conf, looked for iptables, etc. Googled the hell out if it - but still cannot get in. Will ask sysadmin people at work tomorrow. I can see the connection from the husarion cloud server.

I plan to never power the CORE2 down.

Unless you’re going to build it an impressive DC-battery backup PSU, you’ll lose all your progress at the first power outage, just to be a red team for a moment.

But I’ve had similar successes. The idea I have been playing with, but haven’t found a way to test, is that the fault lies with the Asus Tinker board. I’m starting to think that something about the boot-up stops the Tinker board from finding and/or connecting to the network. So the blink we see on L2 after a reboot is just the CORE2 looking for a network connection and waiting until it finds one before doing anything else. This is just a hunch, and is really only a hunch because I haven’t been able to eliminate it.

I’ve been swamped lately, and likely won’t get the kind of time I need to really deep-dive into this problem until mid-late December. But I’ll update my thread if I get lucky and have an epiphany.

I tried ssh again, this time from a different Ubuntu box on the local network, and it failed in the same way. Can’t even ping. I’m also moderately concerned about the huge security hole that the tunnel creates, especially since the Husarion version of Ubuntu seems not to have iptables, UFW, etc. I’m paranoid due to my day job…

In the absence of any feedback from Husarion, I think I will pry the ASUS card off and flash it with TinkerOS and see how I make out there.

Take care.

Hey Terry.

At first I want to apologies you for the time that you have to wait for response. It’s my fault so please don’t blame other members of my team.

We understand what the problem is. Now we are working on it to fix this issue. Until this time, temporary solution is to hold reset button on CORE2 until ASUS Tinker Board will boot themselves (LR2 led will turn on). About your latest post I thing that the best trial to make sure what’s the problem is connect Tinker Board to Screen and check if both computer are in the same WiFi wireless.

Regard,
Hubert.

Thank you Hubert. I can confirm the CORE2 is on on the same wireless as it is visible on the network map provided by my router software. I just tried power cycle while holding the reset and it appears to work, but does not help connectivity issue. Unfortunately I do not have an HDMI capable monitor to attach to the CORE2, so my only connection is via the SSH window on the cloud connection.

The Ubuntu network configuration looks quite different than others I have worked with. I can see it listening on port 22 (after installing openssh) for both IPv4 and IPv6, but still no connection. I will see if I can install tcpdump.

Let me know if you need me to test anything that can ehlp.
Thanks,
Terry

Can you tell me anything more about interface zt0?

Made some progress. I decided to connected the wired gigabit connection. DHCP assigned it the next address and can ssh to it and also run RDP, which is excellent. I found Chromium browser running, which is weird as I did not start it, and presumably was why the load was over 1.0 I’m not sure how to make it work over WiFi, but for now I can continue learning ROS while I’m waiting for a fix.

So a wired connection allowed it to boot normally? No ‘reset power cycle’?

No, sorry - I didn’t test that. It just allowed me to ssh and rdp into the ASUS card. But holding the reset button during power up did work.

Hi Terry.

About your first question - interface zt0 was created by ZeroTier One:

https://www.zerotier.com/download.shtml

It’s a program that creates VPN and makes possible to use your SBC (for example) from another network. You have probably created this VPN unintentionally. Type on console:

sudo zerotier-cli listnetworks

check “nwid” of zt0 and then type:

sudo zerotier-cli leave <nwid>

After these steps, type:

ifconfig

zt0 should disappear. After that, reboot your device. You will probably be able to connect with your SBC via SSH now.

Regards,
Hubert.