Updated Espressif 8266 to 4.0.1 (platform.io), getting time from NTP stopped working on all esp8266/32s. Silently assumes 1970s. Seemingly ignores configTime(MYTZ, "pool.ntp.org", "google.time.com", "time.cloudflare.com"); in time.h code variant.
Tried time.h (https://github.com/esp8266/Arduino/blob/master/libraries/esp8266/examples/NTP-TZ-DST/NTP-TZ-DST.ino)
And NTPClient.h
(arduino-libraries/NTPClient#^3.2.1)
Google is spammed by copy pasted examples around those two.
Is there a working for the setup example?
Related
I'm trying to get the algorithm provided in this repository to work on windows. After countless issues, I'm only left with one unrecognized function cvLoadImage which is apprently depricated. I was instructed to work with the c++ API instead but the problem is that I will have to rewrite other parts of the code as well and I might end up breaking it.
#include <opencv2/imgcodecs/imgcodecs_c.h>
returned the below error on Visual Studio:
"This header with legacy C API declarations has been removed from OpenCV. Legacy contants are available from legacy/constants_c.h file."
I imported all files provided in the opencv folder named constants_c.h, but none contained the function definition.
Indeed, that is the old OpenCV C API. You will need to port the old C functions to the c++ OpenCV API, e.g.:
cvNamedWindow -> cv::namedWindow
cvRectangle -> cv::rectangle
cvPoint -> cv::Point
etc.
The code you're using is actually a mix of the old C API and the newer c++ API.
It's just a matter of going through all the C API calls in that repo and manually port them to the c++ API. As you can see above, most of the time that is fairly intuitive. When in doubt search the OpenCV documentation.
Additionally you should look into YOLOv2 for Pedestrian detection.
Update:
There are multiple forks of this repository and it looks like Berak already has already removed the C API calls. His changes were merged, so you should to pull the latest changes and rebuild:
cd C4-Real-time-pedestrian-detection
git pull
cmake . -DCMAKE_CXX_FLAGS="-std=c++11"
make -j8
I've tested the above on my machine:
Regarding my setup, I ran into this error first:
cvdef.h:656:4: error: "OpenCV 4.x+ requires enabled C++11 support"
which is why I've passed the -std=c++11 compiler flag to cmake.
This may be because I'm an older version of OSX (10.11.6) with Xcode 7.0 (about 3 years old now). The current machine has 8 cores, hence make -j8.
Feel free to change these two options as necessary on your machine.
I work on a 16.04 system, and have successfully installed opencv 3.1 with FFMPEG flags enabled. I double checked this was actually the case by cv2.getBuildInformation() and I got FFMPEG = YES.
I am trying to open a video that is hostel on a private server by my workplace (I am logged in to the VPN, in case thats a concern) and I can access this video over the browser. But videocapture with cv2 fails.
>>> cap = cv2.VideoCapture("https://xxx.mp4", cv2.CAP_ANY) #dummy url
>>> cap
<VideoCapture 0x7f63300fa4b0>
>>> cap.isOpened()
False
This is always the case for https urls. It seems to be able to work with local videos just fine. I have tried a bunch of different thing: initially thought it was a gstreamer problem so I checked my plugins, had some gst-bad versions (ref: https://github.com/GStreamer/gst-plugins-ugly), removed those and replaced with good versions, no joy. Also tried to explicitly tell videoCapture to use cv2.CAP_ANY and cv2.CAP_FFMPEG flags while reading the video, still no luck.
I disabled the Gstreamer flag while compiling opencv, but even with it set to ON, there was no difference in my problem.
I haven't been able to find a solution to this issue and have been looking and trying different things for days now! Any ideas?
Eventually, I gave up on trying to install and reinstall opencv3.1, and switched to opencv 3.4.1. With that, and my current (as original question post) configuration for gstreamer and ffmpeg, I only had to create symlinks for libopencv_core.so.2.4 that gstreamer was looking for, and the rest of it worked fine.
Hope this helps someone!
I haven't managed to figure out what exactly was the issue with opencv3.1 (like I mentioned, that is the configuration my other colleagues have, and the functionality works just fine for them) but this is what I ended up doing after spending days on the issue.
I have an application that is part Polymer Dart and part AngularDart 2, and I'm getting a large string of errors when I attempt to do a pub get. The errors I'm getting look like this:
[DirectiveProcessor]:
Failed with 27 errors
Error 1: line 1, column 1 of lib\common\PaxHeader\service.dart and parts: Expected a method, getter, setter or operator declaration
17 gid=234561557
^^
My Angular dependency is set in my pubspec.yaml as angular2: "2.0.0-beta.22" and I am running Dart 1.19.0 on Windows 7 64 bit. I found this issue on Github:
https://github.com/angular/angular/issues/5599
This seems to be the exact same problem, but was marked as fixed in alpha48 last December, so I'm not exactly sure what could be happening here. I have verified with other teams that this issue is not present on OSX.
Is there something I am missing?
Issue https://github.com/angular/angular/issues/7395 goes into greater detail on what the root cause is - the build process for the bundled archive sometimes includes things that Windows tar handlers don't know how to handle, and the devs at Google don't notice because they're working in Unix. It was supposedly fixed permanently in that issue, but that was before the Dart version branched off to be independent and maybe they didn't copy that bit of setup.
I suggest reporting a new issue at https://github.com/dart-lang/angular2/issues and linking to the old 7395.
Atm, I am integrating Tango's SDK with my game, built with Cocos2dx 3.0, and I encountered this issue where XCode's console printed "libpng error: bad parameters to zlib". Initial tracing of the error showed that a function call in CCImage.cpp, png_read_update_info, terminated prematurely when initialising a png file, resulting in a bad excess error when SpriteBatchNode attempts to add a spritesheet to cache as the texture was not initialised successfully. Furthermore, the one of the lib files in the SDK was found to contain a zlib file.
What exactly is the cause of this issue, usage of multiple zlib? Ultimately, is there anyway to solve this issue on my part, or Tango has to do something about their SDK?
You might link your project with a different version of zlib. I think Cocos2dx 3.0 has already configured zlib well, so you might need to check whether there is another zlib in your Tango's SDK.
Try to remove it and test it again.
Has anyone successfully done a Cooja simulation with a Thingsquare Mist application?
I try to compile the hello-world or the mesh-node examples for the various Mote types but most of them failed on missing ip64-conf.h (naturally, since the target is not supported on Mist) but those that has some sort of Mist port (exp2420 for example) failed because the application can't fit in ROM.
I tried manipulating the line on the Compile commands tab to make it build for any other platform but even though the build is ok the Create button never gets enabled.
I'm using the Instant Contiki 2.6 environment and building code from Thingsquare Mist 1.0.1
Though Thingsquare mist code is based on Contiki 2.6 you can't compile thingsquare code inside instant Contiki (cooja) as it is. The current configuration for make file in mist only supports cc1101, cc2420, cc2538 and two or three platform. Please have a look at thingsquare website for details. Things to do.
You need to change the simulation settings for the specific platform. Do n't waste your time in cooja for running mist apps; it 'll not compile. Have a look to this link: https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja#wiki-Create_a_Hello_World_simulation
For minimizing the missing ip64-conf.h. Just create a ip64-conf.h file inside mesh-node folder and paste the following code.
#ifndef IP64_CONF_H
#define IP64_CONF_H
#include "ip64-slip-interface.h"
#include "ip64-null-driver.h"
#define IP64_CONF_UIP_FALLBACK_INTERFACE_SLIP 1
#define IP64_CONF_UIP_FALLBACK_INTERFACE ip64_slip_interface
#define IP64_CONF_INPUT ip64_slip_interface_input
#define IP64_CONF_ETH_DRIVER ip64_null_driver
#endif /* IP64_CONF_H */
3.To minimize ROM Overflow error; you need to install msp430-gcc compile 4.7.0. Have a look to this link: http://wiki.contiki-os.org/doku.php?id=msp430x