@tom Thanks I am aware of that web GUI. This issue persists regardless of standard Micro Hard setup. But I sort of have a solution and have delivered to the client now. Also knowing about the master slave auto setup timing that works more reliably. I'm essentially off this project. I am interested to know about it because I may integrate VOXLs into future products.
I will consider opening another topic when I have a moment. Thanks for the suggestion and input!
Is it a good idea to cool the VOXL Flight with a small fan? Let's assume it's in an enclosure which is not with open vents but not sealed. We noted both the flight controller and companion computer run pretty hot. What is the ideal operating temperature for these devices? Does operating at a higher heat affect the sensors or board in any way?
@tom I understand and I know many of the questions you get have to do with people not being informed about any of the hardware. I know micro hard and video, linux a good bit, command line I'm comfortable with, but I'm new to VOXL as of this project.
Anyways interestingly we did that (setting static ip on windows), and Windows refused to set the static ip address we set. I think it either had to do with the groundcontrol tablet being a windows tablet but a panasonic tough book, perhaps an odd implementation or the USB ethernet interface of the micro hard somehow not allowing that to be set. The solution for the short term was knowing the VOXL ip address and setting qgroundcontrol to know that through the coms tab, but this wasn't desirable as my solution to the video streaming problem was to use ffmpeg and stream to the ground station's ip address. It can be broadcast as well and of course one could use one of the VOXL's streaming programs, but voxl-streamer doesn't appear to work with that video converter hardware or the setting is not obvious after a few hours of work, and ffmpeg works easily. I had issues getting voxl-uvc-streamer or whatever the name was working properly. It could be that it would work better with that hardware since it's supposed to support UVC better. So we failed to set the computer's ip address from either end, trying first one way and then the other. It's odd, and that's why I thought the auto setup script set something with the dhcp I'm not seeing and the two would each hand out a different ip address depending on who connects first perhaps, I don't know it is unclear.
I was also curious what the time criterion is in the script - is it 5sec +- some range, or >5 but < 10 by some range, etc? A human will never press for exactly 5sec, and this switch is very awkward to press precisely and know it was pressed for that timing. I found a small plastic rectangle was best as it transmits the click sensation better than a finger tip or nail and that helped. It seemed like 5 seconds pressing the button would not cause a reset on our older of the two usb standalones we have. I think it might have an issue. The other one works fine if you could to 5 and release.
I'm sorry my statement was not clear. I am fully aware of the master-slave relationship and requirements, but thank you for clarifying. I am stating that I wonder if having both of them first set by the master script then one manually changed (the usb standalone microhard) to slave properly and the correct ip address for it of 192.168.168.2 (what should be the default, different than 168.1) that something of them both being set by the master auto config script might be causing the ip address hopping. Every reboot of the system would result in the ip address of the ground station changing by one or two up/down.
So that was what I was referring to - the fact that the DHCP server kept changing the ip address of the ground station (this only seemed to appear recently and so may be related to the master-slave auto setup not working due to my timing of the button press), while the setup instructions for connecting the voxl to QGC require an essentially fixed ip address unless one tells QGC what the ip address of the voxl is by setting up another connection in 'coms.'
When I set a fixed ip address on the ground control station side it refused to take on the proper address. It would literally generate a random address. This could be a windows tablet issue, or the usb ethernet issue or a driver issue. If I set a fixed ip address on the microhard web interface page at the network-DHCP tab when a particular mac address connects to it, that system would actually hand out a different one than what I set it to. Am I misunderstanding, doesn't the micro hard DHCP decide what the ip address would be or is the voxl program choosing that/serving the ip address?
Is the micro hard auto config file available on the repo somewhere to review?
We followed the instructions to the letter except for the timing of the push. I'm guessing the master-slave difference might be causing an issue, even after resetting the one micro hard as slave?
@Chad-Sweet - thanks, that's my experience with it, I just wanted to know for sure what it was doing. I think in the documentation it would be helpful to be specific about what direction is normal operation mode, or an off-on type label.
Thank you for the response. So it's a little unclear which side is 'off' for normal operation - does the arrow point to the side that is 'on?' 
In this image from documentation, is the switch on or off?
This is also a really quick one for you guys. I don't feel like the documentation is clear about the precise function and use of the microhard emergency boot switch. The VOXL only functions with it in one position, and the label is not clear what each position means. What are the conditions for each switch position in use? The datasheet page is not clear on this.
Quick question. On the micro hard add-on board and usb standalone - the reset button instructions discuss 5sec hold down and 10sec hold down. Does the different timing determine Master or Slave reset configurations, or is it determined by the board? We are having an issue where the reset keeps making both Master with the same settings and I have to manually alter the settings in Micro hard. Also a new issue that is probably related is the micro hard DHCP server keeps assigning different IP addresses to the ground station. We adapted by telling QGroundControl the ip address of the VOXL, but it is forcing us to change our video streaming strategy. I'd like to know why suddenly this ip hopping seems to be happening.
Thank you. I could not get video from the uvc device over voxl-streamer, though I could access the test video and the stereo cameras/anything plugged into the MIPI ports. I've had a problem with the newer UVC-server program. I need to check my notes it was a few weeks ago but somehow it wasn't working so I fell back on the ffmpeg due to time limits with the intent of going back to the UVC server application as it's a better solution. I will post a specific issue after looking it over again.
We got maybe 1/10 mile in an urban setting, and have had reliability issues. We placed the antennae as far away from power and more than 2.6" from each other on both transmitter and drone. Any recommendations would be helpful. Thank you.
So it sounds like Dan bought the wrong cameras
We confirmed that the PWM is cutting off at the same time, so it's possibly an initial velocity difference thing, unless you guys have other thoughts.
I'm connected also with this. It is the modus project drone. Not a commercially available one. The ESCs are JMRRC 50A version. Running VOXL Flight 1. Motors are kv120 I believe or quite close to that, but chinese brand 4fpv. I'm not sure there is an issue, it may be due to a difference in velocities at disarm. But if the drone is sitting on the bench, and one arms it, spins up the prop-less motors, would the motors achieve significantly different velocities because it might be slightly off level due to the integrator, or does that indicate an issue? There has been discussion between us about the fact that sitting on the grass, bench, ground etc after arm the motors spin up to significantly different velocities. I attribute it to the controller and normal behavior but the other engineers are unsure of it. I think also the larger motors have a much lower rpm in general than tiny motors, so these differences might not be obvious with small drones. Does that seem correct or does there sound like there is a problem?
Also spindown has a different than normal (for small drone) behavior due to the active deceleration/freewheeling mosfet setup rather than diodes I think, but they haven't heard these types of sounds and have concerns that it's a problem. There is a sort of ramping spindown quality.
@Adrian-Hidalgo Thank you for the reply. It's good to have confirmation. That is the link we were going from and I have used in the past.
Hello All, we are using a microhard (the 2.4 GHz model) for all the radio communications to and from the VOXL, so we need pretty robust communications. I have found the application notes around the molex antennae included with the voxl microhard adapter and usb adapter, and used that for antenna placement and orientation. Do you have a sense of, given ideal conditions, the range and reliability of such a datalink using those antennas and do you think a more standard omnidirectional antenna might give superior performance attached at both ends? We need at least 1/2 mile range. I've made some adjustments to the gain and bandwidth of the microhards but we definitely have some reliability issues so far. Any input would be useful even if anecdotal feedback, like "you're crazy to think that would work" type thing, though hopefully something more detailed would be useful:) If you don't think it is possible to get a reliable connection that way and an RC type link is an essential part, please let me know if possible. Thank you for any comments and I appreciate the responses thus far to my questions. I'm enjoying getting to know the VOXL better.
Hello All, we are needing to start a video service to broadcast output from a UVC camera to QGroundcontrol. I was successful streaming with ffmpeg, would like to ultimately use the UVC streaming application to stream over rtsp, but had some trouble getting it functioning, and the deprecated streaming video application did not successfully display a stream (a client connecting would connect/disconnect repeatedly with no video output messages on the VOXL), so I have fallen back on ffmpeg for now. I am familiar with a few options for executing a command at startup like the ffmpeg command, however not for Yocto linux. I wrote a script, placed it in /etc/rc.d, changed the permissions to be executable, and executed "update rc.d myscript.sh defaults" but it doesn't appear to be running upon reboot. I have not yet tried adding an "echo" line in to give me some feedback about what is happening but is this basically the right approach to getting an ffmpeg command to stream uvc video going at startup? Is there a better way? My script is below:
#!/bin/bash -e
#
#Author: C. A. Simpkins Ph.D.
#
#Date: June 5 2022
#
#Description: This script simply executes a command at startup
#to start the video streaming from the camera
#
#
#
#
#this is the command with its options. Change the ip address to be that of the ground station
ffmpeg -i /dev/video2 -f x265 -s:v 640x480 -b 1M -f mpegts -r 15 -aspect 16:9 -muxdelay 0.01 -vf "transpose=2,transpose=2,format=yuv420p" udp://192.168.1.11:4242
#upon success exit
exit 0
Is it possible to use the hi-res camera or wide angle hi-res camera for optical flow tracking (downward looking), or do we need the black and white 640x480 tracking cameras for this purpose? We have the stereo tracking cameras mounted for forward obstacle avoidance and tracking thus far and LiDar for elevation measurements but would ideally also have optical flow set up to track all three movement axes in GPS denied environments. Our purchasing agent bought what he thought were the optical flow cameras and came back with the hi res camera.
Ok. This makes sense. I must have originally seen that during setup but somehow had trouble finding that again. It might be helpful to have an arrow added to the functional description of the voxl flight somewhere.
So if we are mounting our flight 90 degrees clockwise this should be 'YAW90' in the orientation settings for QGC correct? Our GPS/Mag are pointing straight ahead though.