I've had issues setting up the DeepstreamSdk IoTedge module on the jetson nano for the last week and I cannot get past it. I've installed IoTedge runtime and all the necessities for IoT edge to run. It runs perfectly including other modules like the simulated Temperature sensor. However when I deploy the DeepstreamSdk v-4.02 on the Jetson nano running Jetpack 4.3, it starts and runs for a couple of minutes but then fails unexpectedly and then after a bit of time starts up again and then fails again. And then Sometimes I restart the IoTedge and it will start up again and then fail. When I use the Developer extension IoTedge in VS code to see what the messages being sent up to the cloud are, I can see the temperature sensor module's messages, however none from the NvidiaDeepstream module.
I've had a look in the logs for the NvidiaDeepstream container, and it shows that it is printing out results ( messages to the cloud), but then eventually sends an error code 1. and some sort of message at the end INT8 is not supported, try INT16. All the Azure checks and connectivity and configurations are correct. It is just the deepstreamdk module that doesn't run properly.
Does anyone have any suggestions? What info should I provide to make this more clear and understandable? I am following the tutorial on the Github repository for NVIDIA Deepstream + Azure IoT Edge on a NVIDIA Jetson Nano: Link to turorial
Link to logs of COntainers
Related
I'm trying to get IoT Edge Runtime installed on a Windows 10 IoT Core (build 17763 through the IoT Dashboard tool) on a Raspberry Pi 3b (not the plus version!). I'm following this instruction . The IoT Core seems to be running fine. I can connect to it through the device portal. I have a remote PowerShell session opened to the device and I run the command that gets and runs the IotEdgeSecurityDaemon.ps1 script using the command from the mentioned instruction:
. {Invoke-WebRequest -useb aka.ms/iotedge-win} | Invoke-Expression; `
Install-SecurityDaemon -Manual -ContainerOs Windows -DeviceConnectionString 'xxxxxx'
with the connection string being the primary connection string from the IoT Edge device that I added beforehand in the Iot Hub. That all looks fine.
I can see it getting moby-engine (this install script should take care of the installation of the required container engine?) and other prereqs it needs, but in the end, it can't start the iotedge runtime service. This seems related to the moby-engine not running or not being installed (without any logging at all). I have found an alternative IotEdgeSecurityDaemon.ps1 script but before I start using that, I'd like to ask if anyone else has seen the same or similar problem with this particular setup.
regards,
derk
Windows ARM architecture is not yet supported by IoT Edge. AMD64-based IoT Core platforms should work.
See https://learn.microsoft.com/en-us/azure/iot-edge/support#tier-1 for more details.
I am using hector_mapping to create map of my room. I used openni node to get the depth/image_raw from kinect sensor, I then changed it to laser scan data using "depthimage_to_laserscan" and used that "scan" topic to create hector_mapping. When I run all of these in a machine it works fine and creates a map but when I run "openni_launch" and "depthimage_to_laserscan" on odroid and "hector_mapping" on my machine, I get an error the following error: "lookupTransform base_link to camera_depth_frame" timed out. Could not transform laser scan into base frame". What does this error mean and how did it not occur when everything was running on same machine.?
My odroid and machine communicates over a wireless network. My machine runs ROS indigo on Ubuntu Trusty.
roscore
Assuming your roscore is running on your machine, you will have to set the ENV ROS_MASTER_URI variable on odroid to export ROS_MASTER_URI=http://yourmachine:11311 before launching anything on odroid. This will tell the rosnodes on odroid to connect to the roscore on your machine.
Check frame rates and delays
There is tool in the tf package to see the TF tree. This will show you also the delays between the links:
$ rosrun tf view_frames
This will collect TFs for 5 seconds and generate a file named frames.pdf which will contain all the details.
Machine time synchronization
If you see there are large delays between the TF links you can try to synchronize your machines. To do that you synchronize the time clock on your machine to the one which is running the roscore:
$ sudo ntpdate <your-roscore-machine>
Sometimes it takes several synchronization attempts to bring down the time difference between the machines.
I am trying to create a distributed domain using RedHawk 2.0.1 and cannot find enough information on setting it up in the manual. I have two related issues. I want to run the domain manager on the same host as the IDE but run one or more components on another node. I see how to create a new node project but do not see how to specify the network location it should run on. I can add it to the domain but it simply runs two device managers on the local host. I also do not see details of how to make specific components run on the alternate node. Does this require manually adding allocation properies?
The related issue is that I would like to use a non-x86 node as the remote node. I am trying to use an ARM processor and following the instructions in the Sub$100 manual I was able to build and install the runtime system on my ARM, but I find that the GPP device's GPP.spd.xml still has x86 as the processor name while the prf.xml has arm as the required property.
The manual seems to indicate that the binaries for all nodes will be in the sdr of the domain manager, so am I supposed to copy the sdr entries for my arm gpp device and all components back to the sdr of the domain manager host and then they will be deployed back to my arm at domain and waveform launch?
Are there better detailed instructions for distributed domains somewhere that I am missing?
I believe the last supported version of REDHAWK for the Sub$100 project was 1.10, so we're in uncharted territory. That being said, let's take a stab at it.
The first thing you should do is make sure the /etc/omniORB.cfg file for your Domain Manager looks like this:
InitRef = NameService=corbaname::<external IP>:2809
InitRef = EventService=corbaloc::<external IP>10.3.1.245:11169/omniEvents
where should be replaced with your network IP (i.e., not localhost or 127.0.0.1). Restart the CORBA naming and event services with this command:
sudo $OSSIEHOME/bin/cleanomni
The next step is to configure your ARM device to point to the Domain Manager. Edit the /etc/omniORB.cfg file on the ARM device to match the one from your Domain Manager, even the IP address. Note that you don't have to start the naming and event services on the ARM device.
Now for running the GPP on the ARM device, you will have to create that node on the ARM device, since the Domain doesn't know about that device yet and cannnot access its filesystem. Page 16 of the 1.10 version of the Sub$100 document (http://ufpr.dl.sourceforge.net/project/redhawksdr/redhawk-doc/1.10.0/REDHAWK-Sub100-Manual-v1.10.0.pdf) has the instructions for installing the GPP.
Note that the newest version of the GPP is actually a C++ Device now, so the second step should be 'cd framework-GPP/cpp' and the third step should be 'git checkout 2.0.1'. Once that's installed, there are still a couple of more issues to take care of. First, run the following command:
$SDRROOT/dev/devices/GPP/cpp/devconfig.py --location $SDRROOT/dev/devices/GPP
That will configure your GPP to recognize that it is on an ARM platform (as long as your processor is an armv7l processor).
Next, run the following:
$SDRROOT/dev/devices/GPP/cpp/create_node.py --domainname <RH Domain Name>
That will actually create the DeviceManager profile that will contain your GPP.
The final step involves making sure that the node will be configured correctly. Check out Page 21, Steps 5. Basically you can remove the x86_64 implementation and replace any instances of 'x86' with an 'armv7l'.
As for your question about building your components, yes, you have to build them for the platform of interest and then install them to the Domain Manager SDRROOT. If you have a cross-compiler set up to build your components (and the framework), this will make your life a lot easier. However, if you don't, the workaround is to build the components on your ARM device, then install the XML files and the executable to the Domain. In order to make any components work with your ARM GPP, they will need to have an ARM implementation with a processor name that matches that of your GPP in their SPD.
I know that's a lot and I haven't run through these instructions in a while, so let me know if you have any questions or anything doesn't work.
apparently replies are very limited in length so I'll call this an answer. Thanks for your response. I have actually tried part of this but will try to see if your information gets me any further. After writing this question I explored a little further. I found that the code I had compiled on the ARM and installed still had "x86" and "x86-64" in the domain profile for the device manager and no "armv7l" so I patched the profile and tried starting the device manager on the ARM manually (after setting the omniORB.cfg to point to the name server on the domain manager host. It started up fine and said it was trying to connect, and the name server on the domain manager host now had an entry for the ARM device manager but the IDE did not list the additional device manager and if I killed the ARM device manager it said that it was intrupted while waiting to register so I assume that the device manager registered with the name server but never got a reply from the domain manager. This does not make me hopeful that your steps will work, but I'll give them a try.
Update. Following more closely the steps in sub$100 document, it appears that $SDRROOT/dev/devices/GPP/cpp/devconfig.py did not edit GPP.spd.xml to put in the correct processor and compiler version but after hand editing these, I was able launch the full domain (domainManager, deviceManager, GPPdevice) on the ARM processor and was able to connect to this running domain from the IDE running on x86. After exporting and rebuilding my waveform components and editing their domain profiles I was able to use the IDE to launch successfully a very small three component waveform and control it. So running the entire domain on the ARM works ok.
But I still cannot start the deviceManager on the ARM and have it register with the DomainManager on x86 (after editing the DCD to point to the x86 domain, ie, running a distributed domain with two nodes. It starts and says it is registering with the domainManager, and it must partly succeed because the devMgr shows up in the NamingService under the domain, but the IDE never shows the new deviceManager in the domain. And the devMgr never starts the GPPdevice. If the devMgr is killed it prints "Interrupted waiting to register with DomainManager", so even though it got registered into the Naming Service it appears that the DomainManager never replied to the registration request.
What I am looking for: I need help debugging consistently happening system crashes on my Jetson TK1.
System: I am using a Jetson TK1 board from NVIDIA. Updated to 21.3.4 Grinch Kernel. All drivers installed, libopencv4tegra installed alongside ROS (using hacked deb packages to not overwrite openCV). Everything used to work perfectly in this exact setup.
When the crashes happen: I am running a VSLAM program, which uses a camera connected on the USB port. The program is making heavy use of OpenCV. The program used to run for over 1 month without problems in the current setup. Now, I am getting consistent system crashes which result in a total system freeze. When I am connected over ssh, I loose connection. When I connect a monitor to see what happens on the system while it crashes, I can see everything freeze. The USB port also seems to turn off, since not even USB mouse and keyboard work anymore post-crash. The Jetson stays on though.
Crash Logs: I have tried looking into the /var/log/ logs, but none of them show any messages for when the crash happens.
I have run memtester before. It didn't return any bad memory. While running and crashing, the memory onboard is used at about 60-75% (as shown by "top"). CPU usage is around 60%.
The weird thing is that this exact setup has been running just like this for over a month now.
I need to know: are there any other logs I could find information about the crash in? How could I find out if this is related to a hardware failure or whether there's a software issue?
Thanks
-Marc
I am trying to build v1.2 of firefox os for my zte-open. With a few hiccups I was a able to configure and build it using the inari device profile. But the process fails at the last stage of flashing.
here is the output of the ./flash.sh command
rog% sudo ./flash.sh
[sudo] password for abhiram:
< waiting for device >
erasing 'cache'...
OKAY [ 0.531s]
finished. total time: 0.531s
erasing 'userdata'...
OKAY [ 1.399s]
finished. total time: 1.399s
sending 'userdata' (53571 KB)...
OKAY [ 4.518s]
writing 'userdata'...
FAILED (status read failed (No such device))
finished. total time: 9.911s
After that the device starts fresh with no userdata (obviously). Right now I am guessing that if it passes the user-data phase it might flash the system and boot partitions.
Btw, my phone running the version 1.1 of the firmware, which was from an official Zte update.
update
I tried flashing separate partitions of (system and boot) but the it gives me the same error.
with ./flash.sh system
FAILED (status read failed (No such device))
I have this same problem. However I do not think that fastboot is disabled.. I say that because I can see ROAMER2 if I do a
fastboot devices
Please note.. if you cannot preform that command try running the following command first
adb reboot bootloader
after this I bet you will be able to see the devices using the fastboot command.
So fastboot seems to be able to connect to the device and the fastboot command erasing cache seemed to have worked, and the fastboot command erasing userdata command worked. So my guess is that it is not fastboot itself but the device preventing the push from occurring.
Perhaps there is a log we can read somewhere?
Update:
I called the company. Their official line is that they do not support updating the phone and you should only use the Update feature on the phone itself. There is an update coming however it is being pushed out one a time not a global push to all devices. In some blogs on this subject I saw users complain that the device is advertised as open but is not in fact open. Point being this: If the device is preventing the push as I suspect (then we as a consumer have been tricked) and the device is operating correctly.
Update: (more info)
There is a set of problems and it depends on if you upgraded your phone or not. If you read the discussion here I think it pretty much covers everything: http://www.reddit.com/r/FireFoxOS/comments/1ugx5g/firefoxos_buils_for_zte_open/
Also check to see if your device is rooted by the following
adb shell
if you see $ continue to the next command, if you see # you have root
su
If you are in the same boat as me, and have updated to 1.1 using the ZTE images. Then you are a little stuck. We need to downgrade back to 1.0 revision 2 (B02). This will require the clockwork mod recovery to do this. The problem is that we also need the original img. ZTE has taken this image down. If you have this image or if you can find it please upload it and post it here and in the link I provided (you'll be a hero to a very small group of nerds). Otherwise.. a Mozilla developer stated that ZTE will have yet another update coming soon. (However chances are this is going to be yet another locked down version). So the hunt in on for the original image.
After emailing the b2g-dev mailing list, I figured out that this was a problem with the firmware of the zte-open.
AFAIK, the latest firmware update to 1.1 brings all the devices to OPEN_US_DEV_FFOS_V1.10B01 firmware, which for some reason comes with fast-boot disabled. Hence it is not possible to flash it.
It looks like zte are working to bring out a new update that comes with fastboot enabled. So I guess I'll have to just wait it out.
Update
It took me a while to figure out how to update the damn phone, to upgrade you need to downgrade to the firmware 1.0B02 on which fastboot seems to work.
To downgrade I had to install clockworkmod as the default recovery program complains of signature mismatch( Zte! can't I donwngrade to your older official firmware?).
Rooting and installing clockworkmod, I had to remove some assert checks on the device-name from the updater-script and then pack it. Once this is done downgrading the device is quite simple.
After this I had to individually flash the three images (boot,system,userdata) using fastboot flash command