Facing warning: "Nic is not connected to any gates!" in VEINS simulation - omnet++

I'm using Veins 5.0, OMNet++ 5.5.1, SUMO 1.2.0
I'm getting the following warning in my simulation:
WARN (PhyLayer80211p)mpsScenario.node[0].nic.phy80211p: Nic is not connected to any gates!
This is how my mpsScenario.ned file looks:
import org.car2x.veins.base.connectionManager.ConnectionManager;
import org.car2x.veins.base.modules.BaseWorldUtility;
import org.car2x.veins.modules.mobility.traci.TraCIScenarioManager*;
import org.car2x.veins.modules.obstacle.ObstacleControl;
import org.car2x.veins.modules.world.annotations.AnnotationManager;
import org.car2x.veins.nodes.Car;
import org.car2x.veins.mps.traffic.BaseTrafficManager;
network mpsScenario {
parameters:
double playgroundSizeX #unit(m); // x size of the area the nodes are in (in meters)
double playgroundSizeY #unit(m); // y size of the area the nodes are in (in meters)
double playgroundSizeZ #unit(m); // z size of the area the nodes are in (in meters)
string trafficType;
#display("bgb=$playgroundSizeX,$playgroundSizeY");
#figure[description](type=text; pos=700,30; font=,,bold;
text="Aerolink(TM) Misbehavior Protection System Simulation");
submodules:
obstacles: ObstacleControl {
#display("p=240,50");
}
annotations: AnnotationManager {
#display("p=260,50");
}
connectionManager: ConnectionManager {
parameters:
#display("p=150,0;i=abstract/multicast");
}
world: BaseWorldUtility {
parameters:
playgroundSizeX = playgroundSizeX;
playgroundSizeY = playgroundSizeY;
playgroundSizeZ = playgroundSizeZ;
#display("p=30,0;i=misc/globe");
}
manager: TraCIScenarioManagerForker {
parameters:
#display("p=115,60");
}
trafficManager: <trafficType> like BaseTrafficManager {
#display("p=115,0");
}
node[0]: Car {
}
connections allowunconnected:
}
which is basically the default file with one custom trafficManager module. Also, the manager points to TraCIScenarioManagerForker.
The Car.ned module is same as default that is provided by VEINS 5.0.
Since mostly everything is default, I don't understand why I am getting the aforementioned warning. Due to this warning I am getting a std::bad_alloc error as soon as a new BSM is received by a vehicle.
Edit 1: Add MWE which is in github repo
My issue can be recreated using the following steps:
Clone my branch v5 from my fork of veins:
git clone --branch v5 https://github.com/raash1d/veins
Start OMNeT++
Run the simulation from scenarios/mps/omnetpp.ini; choose "Gui" Config name.
Click "RUN" and observe the log messages in OMNeT++ Qtenv window. As soon as a vehicle is created, a warning is generated for the Nic module.
This eventually causes the std::bad_alloc error.

Your OMNeT++ simulation playground is configured (in omnetpp.ini) to go from (0,0) to (10000,10000).
Your SUMO road network (in .net.xml) goes from 0.00,0.00 to 5527.41,7491.84 (this is okay), but your SUMO buildings (in .poly.xml) go from -3255.66,-3540.81 to 5794.35,8029.21.
This means that your simulation will try to use buildings that are outside the playground, which crashes it. You will need to increase the size of the simulation playground.

Related

Arduino IR code not working (USING TINKERCAD)

ARDUINO PROBLEM
**So this is the circuit bord **
THE PROBLEM: when I try to run the code and try to press any button on the IR remote it does nothing ( it doesn't print the hexacode ! )
I have tried to change the circuit and tried to change the code. I was looking fro the arduino forums and tried every one, but still it doesn't work .
Is there a problem with tinkercad. simulation or is it with the code ?
CODE:
https://pastebin.com/1Uhn1j3a
CODE:
#include <IRremote.h>
const int RECV_PIN = A5;
IRrecv irrecv(RECV_PIN);
decode_results results;
void setup(){
Serial.begin(9600);
irrecv.enableIRIn();
irrecv.blink13(true);
}
void loop(){
if (irrecv.decode(&results)){
Serial.println(results.value, HEX);
irrecv.resume();
}
}
Two of the L293D ground pins are, according to your circuit layout, connected to the +5V rail inadvertantly. And the other two are connected to GND. According to this post the grounds are all internally connected, so in effect you would be shorting the +5V output to ground.

Where can I find the mapping of SAMA5D27-SOM1-EK1 devices and it's GPIOS?

I am using SAMA5D27-SOM-EK1 embedded board.
I build for it Linux image OS using YOCTO project version SUMO.
I need to know device's GPIOS ( gpios-leds and gpios keys specialy) and the mapping of the board.
When I enter in /sys/firmware/devicetree/base/leds/red for example in the board terminal I can find gpio file but when i open it there are symbols which i can't read.
I think that I can find such things in the generated Device Tree but i can't find its path!
Please help me out
Here is the original dts: https://elixir.bootlin.com/linux/v5.2/source/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts#L510
The relevant part is:
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_led_gpio_default>;
status = "okay"; /* Conflict with pwm0. */
red {
label = "red";
gpios = <&pioA PIN_PA10 GPIO_ACTIVE_HIGH>;
};
green {
label = "green";
gpios = <&pioA PIN_PB1 GPIO_ACTIVE_HIGH>;
};
blue {
label = "blue";
gpios = <&pioA PIN_PA31 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
};
};
This shows that the red LED is connected to the PA10 gpio, green is on PB1 and blue on PA31.
The other way to find the info is to look at the schematics here:
http://ww1.microchip.com/downloads/en/DeviceDoc/SAMA5D27-SOM1-EK1_Board%20Files_1.B.B.zip
Page 3 of SAMA5D27-SOM1-EK1_REVB.pdf sums the pinmuxing and page 8 shows the actual connection.
Regarding what you want to do (toggling the led if I remember correctly), you can simply have a look at /sys/class/leds/red/brightness writing 0 in that file will turn it off while writing 1, will turn it on.
The device tree sources are available online and are not present in the target system.
Please follow this link
However you could discover how it is working running a sort of reverse engineering using the Device Tree Compiler (DTC) if it is available on the target, run
dtc -I fs /sys/firmware/devicetree/base

Application crashes when asking for a frame that involves COORDINATE_FRAME_CAMERA_DEPTH

I'm using the JPointCloud sample app, and modifying it a little bit:
In JPointCloud.java : SetUpExtrinsics(), I added:
TangoPoseData depth2devicePose = new TangoPoseData();
framePair.baseFrame = TangoPoseData.COORDINATE_FRAME_DEVICE;
framePair.targetFrame = TangoPoseData.COORDINATE_FRAME_CAMERA_DEPTH;
try {
depth2devicePose = mTango.getPoseAtTime(0.0, framePair);
} catch (TangoErrorException e) {
Toast.makeText(getApplicationContext(), R.string.TangoError,
Toast.LENGTH_SHORT).show();
The application crashes when reaching the line:
depth2devicePose = mTango.getPoseAtTime(0.0, framePair);
I tried with other combinations of frame, but each time COORDINATE_FRAME_CAMERA_DEPTH is included, the app crashes.
Did I forget something ? Maybe to ask some kind of special permission for the depth camera ?
It indeed crashes on me as well.
However, according to the Java pointcloud example code (extrinsic query part), the correct way of querying the DEPTH_CAMERA w.r.t(with respect to) DEVICE transformation is using 'the inverse of DEVICE w.r.t IMU' multiply 'CAMAER w.r.t IMU', which is:
deive_T_camera = inverse(imu_T_device) * imu_T_camera
Also, note that the color camera, depth camera and camera are the same camera on the hardware level, so they actually share the same extrinsic.
Hope this helps.
Edit: the crashes actually throw an com.google.atap.tangoservice.TangoInvalidException. This might just be a frame pair not supported from API level, as mentioned before, the suggested way would be using other two matrices to compose the desired matrix in this case..

How to monitor a folder for new files in swift?

How would I monitor a folder for new files in swift, without polling (which is very inefficient)? I've heard of APIs such as kqueue and FSEvents - but I'm not sure it's possible to implement them in swift?
GCD seems to be the way to go. NSFilePresenter classes doesn't work properly. They're buggy, broken, and Apple is haven't willing to fix them for last 4 years. Likely to be deprecated.
Here's a very nice posting which describes essentials of this technique.
"Handling Filesystem Events with GCD", by David Hamrick.
Sample code cited from the website. I translated his C code into Swift.
let fildes = open("/path/to/config.plist", O_RDONLY)
let queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)
let source = dispatch_source_create(
DISPATCH_SOURCE_TYPE_VNODE,
UInt(fildes),
DISPATCH_VNODE_DELETE | DISPATCH_VNODE_WRITE | DISPATCH_VNODE_EXTEND | DISPATCH_VNODE_ATTRIB | DISPATCH_VNODE_LINK | DISPATCH_VNODE_RENAME | DISPATCH_VNODE_REVOKE,
queue)
dispatch_source_set_event_handler(source,
{
//Reload the config file
})
dispatch_source_set_cancel_handler(source,
{
//Handle the cancel
})
dispatch_resume(source);
...
// sometime later
dispatch_source_cancel(source);
For reference, here're another QAs posted by the author:
Grand Central Dispatch (GCD) dispatch source flags
Monitoring a directory in Cocoa/Cocoa Touch
If you're interested in watching directories, here's another posting which describes it.
"Monitoring a Folder with GCD" on Cocoanetics. (unfortunately, I couldn't find the author's name. I am sorry for lacking attribution)
The only noticeable difference is getting a file-descriptor. This makes event-notification-only file descriptor for a directory.
_fileDescriptor = open(path.fileSystemRepresentation(), O_EVTONLY)
Update
Previously I claimed FSEvents API is not working, but I was wrong. The API is working very well, and if you're interested in watching on deep file tree, than it can be better then GCD by its simplicity.
Anyway, FSEvents cannot be used in pure Swift programs. Because it requires passing of C callback function, and Swift does not support it currently (Xcode 6.1.1). Then I had to fallback to Objective-C and wrap it again.
Also, any of this kind API is all fully asynchronous. That means actual file system state can be different at the time you are receiving the notifications. Then precise or accurate notification is not really helpful, and useful only for marking a dirty flag.
Update 2
I finally ended up with writing a wrapper around FSEvents for Swift.
Here's my work, and I hope this to be helpful.
https://github.com/eonil/FileSystemEvents
I adapted Stanislav Smida's code to make it work with Xcode 8 and Swift 3
class DirectoryObserver {
private let fileDescriptor: CInt
private let source: DispatchSourceProtocol
deinit {
self.source.cancel()
close(fileDescriptor)
}
init(URL: URL, block: #escaping ()->Void) {
self.fileDescriptor = open(URL.path, O_EVTONLY)
self.source = DispatchSource.makeFileSystemObjectSource(fileDescriptor: self.fileDescriptor, eventMask: .all, queue: DispatchQueue.global())
self.source.setEventHandler {
block()
}
self.source.resume()
}
}
The simplest solution is to use Apple's DirectoryMonitor.swift
https://github.com/Lax/Learn-iOS-Swift-by-Examples/blob/master/Lister/ListerKit/DirectoryMonitor.swift
var dm = DirectoryMonitor(URL: AppDelegate.applicationDocumentsDirectory)
dm.delegate = self
dm.startMonitoring()
Swift 5 Version for Directory Monitor, with GCD, original from Apple
import Foundation
/// A protocol that allows delegates of `DirectoryMonitor` to respond to changes in a directory.
protocol DirectoryMonitorDelegate: class {
func directoryMonitorDidObserveChange(directoryMonitor: DirectoryMonitor)
}
class DirectoryMonitor {
// MARK: Properties
/// The `DirectoryMonitor`'s delegate who is responsible for responding to `DirectoryMonitor` updates.
weak var delegate: DirectoryMonitorDelegate?
/// A file descriptor for the monitored directory.
var monitoredDirectoryFileDescriptor: CInt = -1
/// A dispatch queue used for sending file changes in the directory.
let directoryMonitorQueue = DispatchQueue(label: "directorymonitor", attributes: .concurrent)
/// A dispatch source to monitor a file descriptor created from the directory.
var directoryMonitorSource: DispatchSource?
/// URL for the directory being monitored.
var url: URL
// MARK: Initializers
init(url: URL) {
self.url = url
}
// MARK: Monitoring
func startMonitoring() {
// Listen for changes to the directory (if we are not already).
if directoryMonitorSource == nil && monitoredDirectoryFileDescriptor == -1 {
// Open the directory referenced by URL for monitoring only.
monitoredDirectoryFileDescriptor = open((url as NSURL).fileSystemRepresentation, O_EVTONLY)
// Define a dispatch source monitoring the directory for additions, deletions, and renamings.
directoryMonitorSource = DispatchSource.makeFileSystemObjectSource(fileDescriptor: monitoredDirectoryFileDescriptor, eventMask: DispatchSource.FileSystemEvent.write, queue: directoryMonitorQueue) as? DispatchSource
// Define the block to call when a file change is detected.
directoryMonitorSource?.setEventHandler{
// Call out to the `DirectoryMonitorDelegate` so that it can react appropriately to the change.
self.delegate?.directoryMonitorDidObserveChange(directoryMonitor: self)
}
// Define a cancel handler to ensure the directory is closed when the source is cancelled.
directoryMonitorSource?.setCancelHandler{
close(self.monitoredDirectoryFileDescriptor)
self.monitoredDirectoryFileDescriptor = -1
self.directoryMonitorSource = nil
}
// Start monitoring the directory via the source.
directoryMonitorSource?.resume()
}
}
func stopMonitoring() {
// Stop listening for changes to the directory, if the source has been created.
if directoryMonitorSource != nil {
// Stop monitoring the directory via the source.
directoryMonitorSource?.cancel()
}
}
}
I've tried to go with these few lines. So far seems to work.
class DirectoryObserver {
deinit {
dispatch_source_cancel(source)
close(fileDescriptor)
}
init(URL: NSURL, block: dispatch_block_t) {
fileDescriptor = open(URL.path!, O_EVTONLY)
source = dispatch_source_create(DISPATCH_SOURCE_TYPE_VNODE, UInt(fileDescriptor), DISPATCH_VNODE_WRITE, dispatch_queue_create(nil, DISPATCH_QUEUE_CONCURRENT))
dispatch_source_set_event_handler(source, { dispatch_async(dispatch_get_main_queue(), block) })
dispatch_resume(source)
}
//
private let fileDescriptor: CInt
private let source: dispatch_source_t
}
Be sure to not get into retain cycle. If you are going to use owner of this instance in block, do it safely. For example:
self.directoryObserver = DirectoryObserver(URL: URL, block: { [weak self] in
self?.doSomething()
})
SKQueue is a Swift wrapper around kqueue. Here is sample code that watches a directory and notifies of write events.
class SomeClass: SKQueueDelegate {
func receivedNotification(_ notification: SKQueueNotification, path: String, queue: SKQueue) {
print("\(notification.toStrings().map { $0.rawValue }) # \(path)")
}
}
if let queue = SKQueue() {
let delegate = SomeClass()
queue.delegate = delegate
queue.addPath("/some/file/or/directory")
queue.addPath("/some/other/file/or/directory")
}
Easiest method I've found that I'm currently using is this wonderful library: https://github.com/eonist/FileWatcher
From README
Installation:
CocoaPods pod "FileWatcher"
Carthage github "eonist/FileWatcher" "master"
Manual Open FileWatcherExample.xcodeproj
let filewatcher = FileWatcher([NSString(string: "~/Desktop").expandingTildeInPath])
filewatcher.callback = { event in
print("Something happened here: " + event.path)
}
filewatcher.start() // start monitoring
I faced a problem that is not mentioned in any of the answers. As my app is using a UIDocumentBrowserViewController (i.e. Apple's own Files app) to manage its documents, I have no control over my users' habits. I was using SKQueue to monitor all files in order to keep metadata in sync, and at a certain point the app started crashing.
As it turns out, there is an upper limit of 256 file descriptors that can be open by an app simultaneously, even just for monitoring. I ended up combining SKQueue and Apple's Directory Monitor (reference to which you can find in this answer of the current thread) to create a class I named SFSMonitor, which monitors a whole queue of files or directories by using Dispatch Sources.
I detailed my findings and the practices I now use in this SO thread.
You could add UKKQueue to your project. See http://zathras.de/angelweb/sourcecode.htm it's easy to use. UKKQueue is written in Objective C, but you can use it from swift
Depending on your application needs, you may be able to use a simple solution.
I actually used kqueue in a production product; I wasn't crazy with the performance but it worked, so I didn't think too much of it till I found a nice little trick that worked even better for my needs, plus, it used less resources which can be important for performance intensive programs.
What you can do, again, if your project permits, is that every time you switch to your application, you can just check the folder as part of your logic, instead of having to periodically check the folder using kqueue. This works and uses far less resources.

Creative Gesture Camera in Processing

I'm trying to use the creative gesture camera in Processing. I started with the Intel Perceptual Computing SDK, and ran into an issue.
I want to get the hand openness, and I am running into some issues - no matter what, the hand.openness returns 0. It otherwise runs quite well...
Some Sample code I'm trying to get to work: If you open your hand it starts printing to the console, close it and it stops.
import intel.pcsdk.*;
PXCUPipeline session;
PXCMGesture.GeoNode hand = new PXCMGesture.GeoNode();
void setup()
{
session = new PXCUPipeline(this);
if(!session.Init(PXCUPipeline.GESTURE))
exit();
}
void draw()
{
background(0);
if(session.AcquireFrame(false))
{
if(session.QueryGeoNode(PXCMGesture.GeoNode.LABEL_BODY_HAND_PRIMARY|PXCMGesture.GeoNode.LABEL_OPEN, hand)) //Only when primary hand is open
{
rect(0, 0, 10, 10);
println(hand.openness + " : " + frameCount); //Openness should be from 0 to 100
}
session.ReleaseFrame();
}
}
Using the current version of Processing (2.0.3), Perceptual Computing SDK Version 7383.
Try updating the version of the SDK you're using if your project will allow it, there were quite a few bugs with getting attributes such as openess, openessState, radius, to name a few with the processing library (some attributes would even throw a null pointer exception when trying to retrieve them). I believe these have all been fixed in the recent versions, along with the inclusion of 64 bit processing support.

Resources