Recommendation : Vision Seek or Flir One

Hi @fnoop,
We are planning to use a Raspberry pi 3 as a companion computer to an Iris+ 3DR with a pixhawk and Drone kit to autonomously navigate the drone. We are looking to buy a thermal camera which would typically detect a hot or cold object and return coordinates of its location. We see that Maverick supports both Flir one and Vision Seek. Which one would you recommend ?

Thank you

Of course any input from anyone is also most appreciated :slight_smile:

Hi, honestly unless youā€™re doing a fun little hobby project, I wouldnā€™t use either. The Seek company promised an API but never delivered. The reversed engineered opensource solutions are really good but not perfect - there are bus dropouts and lack of access the proprietary magic that does all the thermal and blackspot corrections. But the main problem is that neither hardware is designed to be run ā€˜headlessā€™ from an embedded computer. The form factor doesnā€™t lend itself well, the Flir turns itself off, cables are hard to get etc . If youā€™re determined you could probably make a decent project from the seek thermal, I would avoid the flir because you have to physically turn it on separately, and it has a separate battery. Iā€™ll add a note to the Maverick docs to this effect - I added support because I got the devices eager to make a cheap solution, but sold them both because they werenā€™t really that useful in real world terms.
If you can afford it, buy a proper thermal imager like the Flir Vue, or I think there are now cheaper chinese alternatives.

Hi @fnoop! Thanks for the detailed answer ! Even though itā€™s not exactly what we wanted to hear :joy:
To be fair (to the inexpensive hardware), we donā€™t plan on using either for our eventual product/solution but we were hoping for a cheap way to put together a proof of concept (drone images, find spots/targets , tell GS/web server, in turn tells other drones and assign targets) so at this moment, itā€™s more a fun hobby project magnitude than a production solution. We would more likely eventually buy a drone that readily offers the capabilities we are looking for (far from limited to IR camera) or experiment with ā€œrealā€ cameras.

For now, what Iā€™m hearing, is that between the two , you would recommend the Seek? (Without really recommending either :wink: )
For our first iteration, having to turn the camera on manually is not a big deal, what matters more is being able to pipe the feed / images into an onboard simple detection code (which we donā€™t have) to test this architecture I mentioned above. (At the moment the imaging drone just ā€œmakes upā€ random targets for the other drones to be assigned to )
Iā€™ll check in the Flir Vue but I imagine itā€™s not within budget reach until we kick this project up a notch (given that we need quite a few quads to construct a scaled version of said architecture)
Thanks again !

I like your determination :slight_smile: Yes out of the two I would definitely choose the seek - itā€™s cheaper, lighter, easier to work with and is more reliable in a drone because you donā€™t have to manually operate it. For a proof of concept it would probably do the job - I did try it pointing downward from a small drone hanging off a pi zero and I could pick out me and my dog from the air (canā€™t remember the altitude), so it does work!
You could also look at the various carriers for the flir lepton, which is the sensor behind the flir one. That allows it to be used in a much more friendly form factor, and the lepton3 has similar resolution to the seek thermal.

1 Like

Ahhhhh now that sounds more like it :slight_smile:
Seek, it is. Iā€™ll look into the lepton as well but the Maverick readily supported factor is important as weā€™re completely new to the world of ArduPilot, Dronekit, Mavlink,ā€¦and all.
Iā€™ve been eyeing Seeks and Flirs on OfferUp and eBay and such, but the Android USB versions are not as available.

Also, we may have more questions as we run with it all, as we plan on using Maverick heavily :slight_smile:

Hi @fnoop! Iā€™m working with @loicspace on this project and finally catching up with everything that has been going on :smile: and I have an update for you with further pleas lolā€¦

So we did get the Seek and set it up with the Pi Zero, and get the service to work with the output written to the avi file. Iā€™m having issues accessing the SD card ATM but I hope Iā€™ll get through and check whether the video files were actually written to it. The bigger issue arises when we try to stream it with the raspberry h264 and try to restart the seek service, which seemingly doesnā€™t seem to happen (ref: following SS) and Iā€™m not sure what we might be missing over here. The default start of the service has been enabled in localconf as well.


Another issue weā€™ve been facing is with enabling webvision. I added the localconf parameter "maverick_vision::webvision_active": true as specified in the maverick docs (http://goodrobots.github.io/maverick/current/#/modules/vision?id=vision_seek) and configured it. The service doesnā€™t get enabled however and trying to access webvision on my browser gives Bad Gateway (ref: following SS)


I wonder if the parameter command has a typo, should it be "maverick_vision::webvision::active": true instead ( :: in place of _ )?

Do let me know your thoughts and I appreciate any inputs.

Hi Sameer! Couple of things to note:

  • The seek doesnā€™t stream easily. I could never find the right conversion magic to convert the thermal data to streamable rgb visible video. Iā€™m sure itā€™s possible - after all it saves to a video file - just needs someone to work out the right gstreamer combination.
  • webvision: the correct parameter is actually maverick_vision::visiond::webvision_active: true - sorry the docs are wrong! You can find the corresponding manifest entry for the parameter here: https://github.com/goodrobots/maverick/blob/stable/manifests/maverick-modules/maverick_vision/manifests/visiond.pp#L4
  • webvision: Note that webvision relies on the old nsapi browser plugin spec which is deprecated now, and almost certainly doesnā€™t work in modern chrome browsers. Itā€™s a shame as it was a clever solution to the problem and itā€™s a complete mystery why browsers donā€™t support rtsp streaming inherently. last time I looked, there was no alternative but I have a plan to implement a standards based solution (webrtc) in the future.

Please feel free to head over to our gitter channels for a bit of realtime help :slight_smile:

Thanks for the reply!
Thatā€™s unfortunate though, regarding streaming the Week, as for our project, being able to relay the video feed to the ground is imperative. Weā€™ll try to play with the conversion but I doubt weā€™ll be more successful than you were. Might need to experiment with the less convenient Flir instead then.
Streaming aside, does the same issue arise if we want to capture the feed to use for on board processing? Maybe using Open CV to detect hot spots.
We may see you on Gitter soon :wink: