I'm controlling a DC motor and PS3 controller with Beaglebone Black. For PS3 I'm using this git repo.
DC motor and PS3 works fine with BBB and using jstest for monitoring PS3 but when motor applies some impulsive torque or stops mometorily, PS3 hangs or its connection lost to BBB.
I won't be able to get reading form jstest. I have to restart BBB to make PS3 work again.
Can someone tell me what's going on and how to solve this issue.
Do NOT power high loads directly from the BBB! Use the io pins to control a FET or a relay and make sure the power supply is sized sufficiently and possibly add some larger capacitors to buffer supply voltage drops. Or even better use a separate supply for each.
Related
I have a logitech C920 Web camera.
I was able to follow this https://stackoverflow.com/a/42819965 to get the autofocus turned off and manually set the desired focus while I ran the python code on My Windows 10 pc. Also, I could see the changes in focus when adjusting value.
But when I tried to connect the same camera to Raspberry Pi (3 B+ ) and run the same code, for whatever the value of focus I set, it just doesn't respond. Same blurry images always.
What could be the possible reason for this?
Depends on the driver and/or video backend used by cv::VideoCapture.
You can try setting the focus directly with v4l2-ctl:
https://www.christitus.com/logitech-c920-linux-driver/
When using Lua and the GPIO module with my NodeMCU, my the high and low values are occurring in reverse.
I downloaded my build from NodeMCU custom builds: Link
To turn on the blue LED on the ESP8266, normally you set GPIO pin 0 to high. What's happening for me is I have to set it to low.
This is what I'm executing in the serial console to light up the blue LED:
gpio.write(0, gpio.LOW)
If I take this pin and directly connect it to ground, it also lights up the blue LED which I believe is correct.
What's causing my low and high values to be read incorrectly in NodeMCU?
This is normal - the on-board LED turns on with a LOW value and turns off with a HIGH value.
I've programmed these both in Lua and Arduino and the on-board LED works the same way.
Try attaching a regular LED to the same pin. You'll notice that it's inverse -- it will turn on with a HIGH value and off with a LOW value.
HIGH means the pin is set to supply voltage (it is "sourcing" voltage) and LOW means it is set to 0V (it is "sinking" voltage).
Assuming this board is wired like most of them, this is the rough schematic of the LED (note that "0" in gpio.write refers to GPIO16 hardware pin per the diagram here):
Diagram of the GPIO16 pin
You can see the diode is "pointing" in the direction that current should flow through it for the diode to light, which is "towards" GPIO16. So to get current to flow you need to set GPIO16 to LOW (0V) so there is a voltage difference. Otherwise both sides of the diode are at 3.3V and no current flows.
So I have a BeagleBone Black board, and I want to be able to set some GPIO pin from a low value to a high value.
For achieving this I'm using the BlackLib1 library (a C++ library that offers general access to all beaglebone's pins).
That library haves a class called BlackGPIO that offers the functionality that I want.
BlackLib::BlackGPIO NSLP_pin(BlackLib::GPIO_61, BlackLib::output, BlackLib::SecureMode);
auto NSLP_pinMode = NSLP_pin.getValue();
NSLP_pin.setValue(BlackLib::low);
I expect that this lines of code will set the signal from a low value to a high one (the signal is low by default).
The problem is that the signal goes high only for about ~10ms (measured on a scope), and after that it goes low again.
What I do wrong?
How can I set the some GPIO pin at a certain value, and remain like that until I change it?
[1] link
The link specifies to export the BBB pins from command line and to set it HIGH or LOW. You can develop a small C++ function to send those commands to kernel to export, ON/OFF the BBB pins. I'm using the same method in my C application and it works perfect.
Example code snippet in C to Enable the pin:
FILE *GPIO;
GPIO = fopen("/sys/class/gpio/gpio65/direction", "w");
fseek(GPIO,0,SEEK_SET);
fprintf(GPIO,"61");
fflush(GPIO);
fclose(GPIO);
I want to make something like they have at US dmv's where you sit down and it takes your picture, maybe like photobooth.
I want to connect a high end camera via usb, fire the camera and get the picture.
There's the Picture Transfer Protocol http://en.wikipedia.org/wiki/Picture_Transfer_Protocol a nastly little thing. All the cameras I held in my hands so far, claiming they had proper PTP support failed it somewhere. But in theory one can use PTP to remote control a camera, i.e. trigger the shutter, retrieve the picture and so on.
Rater than reimplementing the whole thing I recommend you get some readily usable PTP library. There are some open source ones listed on http://ptp.sourceforge.net
The easiest method is probably to use OpenCV: http://opencv.willowgarage.com/wiki/
If you need a high end camera - most digital SLRs have a tethered mode where you can control the camera, fire the shutter and retrieve the image data. Each camera maker has a proprietary (but normally free) sdk.
For a webcam type camera - these normally run in video mode, you simply grab an image out f the video stream - as PaulR says - use openCV
I'm looking to create a hardware accelarated DirectX (9 at the moment) window on a secondary screen. This screen is connected to the same graphics display as the primary screen (at least at the moment).
Currently, when I try to open the window on the secondary screen based on window position or by dragging it there, CPU usage jumps by about 10%, which seems to indicate that windows is switching to a software fallback rather than the hardware accelaration.
Machine is windows XP running a NVIDIA graphics card (varying cards as this runs on several machines), with the latest driver. It's also running CUDA at the same time to produce the images if that matters. Programming language is c++, manual window and message queue creation, no tookbox used at the moment to manage the GUI
Thanks
When you call CreateDevice, make sure to use the index of the monitor you are targeting. The standard D3DADAPTER_DEFAULT value is just 0, which is the primary monitor. DirectX is a bit kludgy that way, but if the window is on a different monitor than is specified in CreateDevice, then it will silently render in a framebuffer targeting the first monitor, then buffer copy to a framebuffer on the second monitor using the OS window manager.
So, the quick and dirty solution is to use CreateDevice(1, ...) instead since that is almost always be how a dual monitor setup is indexed.
A more robust solution is to use MonitorFromWindow(hwnd) to find the monitor that the window covers the most, then iterate through available d3d adapters looking for one that returns the same monitor handle using GetAdapterMonitor(). If you have a system with more than two monitors, or if you don't know in advance what monitor you want and just have an HWND, then you need the longer method.