In a professional context, I have to use the vl53L0x. This sensor was released recently, along with it's API, meaning that there's no help on the internet yet :
http://www.st.com/content/st_com/en/products/embedded-software/proximity-sensors-software/stsw-img005.html
This API contains some source and headers file, that I compiled with the gcc. It works fine, despite clearly lacking comments. I flash the memory of a stm32 (NUCLEO-F401RE), which controls a vl53L0x sensor via an I2C bus. I now want to add more vl53L0x sensors on the same I2C bus, and refer to this document (if you want to read it, go directly to the bottom half of the page 5, the wiring is already done) :
http://www.st.com/content/ccc/resource/technical/document/application_note/group0/0e/0a/96/1b/82/19/4f/c2/DM00280486/files/DM00280486.pdf/jcr:content/translations/en.DM00280486.pdf
The principle, that I already applied on other sensors, is that they all start with the same address. You then have to activate one, change it's address, then activate the next one, change it's address, etc.
Unfortunately, ST Microelectronics didn't publish the list of the I2C registers, so I have to use their API to control multiple sensors. The document linked above explains how to do so. Among other things, it specifies :
In vl53L0x_platform.h API file
• Set VL53L0x_SINGLE_DEVICE_DRIVER macro to 0 so that API implementation will
be automatically adapted to a multi-device context.
I looked everywhere in the API folder, I was not able to find any reference to a VL53L0x_SINGLE_DEVICE_DRIVER macro. Setting it to 0 won't change anything, as this string is not present anywhere in the API files. Did anyone run into a similar problem ?
I'm working on the same thing. It seems that you're further ahead than I am. However, putting this in my while(1) loop seems to make both the sensors work.
ResetAndDetectSensor(0);
TimeStamp_Reset();
The guide says that in order to use all the sensors simultaneously, you need to pull the XSHUT pin high for all the sensors, reset the timestamp and then pick up the sensor which actually detects something.
Related
I am currently using dronekit-python to implement somewhat of a Mission Planner clone, as an API. I've generally been able to replicate most important features from Mission Planner; however, some features don't seem to be present.
One such feature is reading live servo outputs, which can be done in Setup > Mandatory Hardware > Servo Output (image below). I have been able to emulate getting/setting the output's function, min, trim, max, and reversed values through parameters. However, I cannot seem to access the live position values through dronekit. How would you go about this?
A second feature is reading specific values from the plane, beyond the class attributes present. This is available in Mission Planner when double-clicking a value in the Quick pane in order to change what measurement is displayed (image below). For my use case, I'd like to specifically access battery_voltage2 and battery_remaining2, as these are vital measurements for our system. I tried using vehicle.battery in dronekit, but this seems to only display data from battery 1. Any ideas?
Thank You so much for the help!
It might be possible to get the battery information and other information from the drone by using Mavlink messages. For battery information, look at the BATTERY_STATUS (#147) Mavlink message. For servo information, look at the SERVO_OUTPUT_RAW (#36) message.
In order to receive these messages, look into using message listeners from dronekit-python. You should be able to receive and parse the Mavlink message.
In general, you can use message listeners and the dronekit-python message factory to receive and send Mavlink messages, which allows you more control than some of the built-in dronekit functions. If you decide to control the drone this way, though, be careful because it's pretty easy to mess up your logic and have the drone behave unexpectedly.
Hope this helps!
I am learning to rewrite the code for the microcontroller integrated in the development Sim modules (such as Sim800C) to be able to control switching a device without having to use another MCU. If we can do that, we only need to add 1 transistor to be able to control a relay on and off.
I know at the output of the MCU (eg STM32F...) inside the sim module (eg sim800C) there will be a function to receive and read personal information stored in the sim card and decode the signal emitted from the Mobile base station: For example, when a call comes in, it will generate the sequence:
RING
+CLIP: "01203360211",161,"",0,"",0
....
So can anyone help me to know when the MCU outputs a string like the above, what will be its input 11110000,...? or something special in some form? I'm really confused. Thanks everyone!
I am a student and new to Pspice, I am given the following example circuit
and asked to created the following circuit,
which I have this
I think I have my circuit designed correctly. However, I am having trouble with finding the correct diode. I have tried different library such as diode, ediode, diode_bridge, on_diode and infineon, but the diodes from these library don't give a current of 20mA(typically lower than that). I also tried to find discrete.olb, however it's not in my capture library.... Is there any other library contains the 2legs led like the diodes in example circuit?I think the reason why I am not getting 20mA is because of the diode?
As can be seen here on the PSPICE website, you should be able to find all of the LED models in the Optoelectronics->LEDs library.
Assume a pci-driver for the linux-kernel. This device can have multiple channels that can be "up'ed" or "down'ed" individually.
Each "up" calls the function .ndo_open and each "down" calls .ndo_stop.
This device needs only one interrupt-line which can be requested with request_irq (). Each request will create one interrupt-line.
Important to note here is, that interrupt-lines are rare and they should not be created mindless.
My question to this situation is, where should I use request_irq()?
In my opinion I have two possible solutions for this.
Right in the probe(). This will only create one interrupt-line but it will always be created when the pc is turned on. So it might be unused.
In .ndo_open. This will create the interrupt-line only when it is needed, but a multichannel device can create mutliple calls of .ndo_open which will result in multiple calls of request_irq()
I was not able to find any information about this situation in the kernel docs. If there is some guideline for this, can you please explain/show it to me? I also checked other pci-drivers from the git-repo but none (or at least the ones I checked) had this problem.
I have Ardupilot on plane, using 3DR Radio back to Raspberry Pi on the ground doing some advanced geo and attitude based maths, and providing audio feedback to pilot (rather than looking to screen).
I am using Dronekit-python, which in turn uses Mavproxy and Mavlink. What I am finding is that I am only getting new attitude data to the Pi at about 3hz - and I am not sure where the bottleneck is:
3DR is running at 57.6 khz and all happy
I have turned off the automatic push of logs from Ardupilot down to Pi (part of Mavproxy)
The Pi can ask for Attitude data (roll, yaw etc.) through the DroneKit Python API as often as it likes, but only gets new data (ie, a change in value) about every 1/3 second.
I am not deep enough inside the underlying architecture to understand what the bottleneck may be -- can anyone help? Is it likely a round trip message response time from base to plan and back (others seem to get around 8hz from Mavlink from what I have read)? Or latency across the combination of Mavproxy, Mavlink and Drone Kit? Or is there some setting inside Ardupilot or Telemetry that copuld be driving this.
I am aware this isn't necessarily a DroneKit issue, but not really sure where it goes as it spans quite a few components.
Requesting individual packets should work, but that was never meant to be requested lots of times per second.
In order to get a certain packet many times per second, set up streams. A stream will trigger a certain number of times per second, and will then send whichever packet is associated with it, automatically. The ATTITUDE message is in the group called EXTRA1.
Let's suppose you want to receive 10 ATTITUDE messages per second. The relevant parameter is called SR0_EXTRA1. This defines the number of Attitude packets sent per second. The default is 4. Try increasing that parameter to 10.