To create a valid SBC Linux Image we need to know what software that would be useful to a new comer to have pre-installed.
Statring with Ubuntu 14.04 LTS for ODROID /RPi2
Additional Software would be
System Software
- FTDI USB support (drivers are built in)
- Python
- WiFi Support (As Client and Access Point)
- DHCP and DNS Support
- LTE Module Support (needs list of compatible devices)
- OpenCV + Python Bindings
- OpenVPN support for secure connections
- gstreamer-1.0
Drone Software
- MAVProxy
- DroneAPI
Python Applications
- Randy's Balloon Finder
- Drone API examples
Bootup to start MAV Proxy and other Python software in know configurations
[LATER] Also
- Inadyn
- dnsutils
- modeswitch
- proftpd
- VLC (Some people prefer VLC over gStreamer)
- Uqmi ? (True LTE support. Widely used by OpenWrt)
Replies
Hello JB
OBC.... I am just like Joe now, got lost in translation :-))
Thanks for you very valuable comments, and YES you are right about the design philosophy starting from the user backward to the plumbing.
Talking about plumbing , I invite you to take part of the discussion about system architecture here so basically we try to all agree on where should the kitchen sink should be located before starting cooking.
Glad we agree Randy.
Always happy to be of assistance if you need someone to bounce ideas off! ;-)
--
Lol Patrick :-)
No Probs!
See you there for more discussion on the hardware architecture!
Ok, a lot of good stuff in the replies above and in line with what I've been thinking.
So I agree that we should allow the Wifi AP to be either on the ground (like Solo does) or in the air (like the Bebop does). It's also definitely in my mind that there could be two access points in a full system - one on the drone and another on a NAVIO+ acting as antenna tracker and ground based companion computer which creates an AP so other GCSs (like Tower, MP) can connect and get info (indirectly) from the drone.
I also agree we will need a web based configuration tool eventually. So the user will connect to the AP and visit a particular URL which will display a configuration web page.
oh, and my preferred ( and fast ) streamer is this command:
mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 640x480 -f 25" -o "output_http.so -p 8080 -w /www/webcam" &
oh, and this URL is helpful.... http://petrkout.com/electronics/low-latency-0-4-s-video-streaming-f... for when u want to *receive* the video, I found their very simple "
rpi-stream.py" to be just about as fast as it gets .. on my laptop anyway.@davidbuzz
I really like mjpg-streamer , it works fine and only takes 4% of processing. I does stream directly in Mission Planner and runs with minimum latency over tcp.
Looking at the URL you linked to , it is like connecting a remote webcam within opencv. I doubt that this would be pratical for balloon_finder because it add too much latency in the process.
Regarding the downlink stream:
A) What do we want to stream ?
The source signal (usb camera)
or we are more interested by opencv post-processing showing the ROI (Region Of Interest) ?
Both
B) When do we need to stream ?
All the time : It requires a big budget on power-Bandwidth-Processing
When we have positive detection ?
On request
It all depends on Processing Power, Bandwidth and Latency. The major problem I experienced with the BeagleBone was that the USB get stuck on high video traffic. .. That was a major problem with Kernels 3.xxx and it was a lesser problem with kernels 4.x. I did these experiment at the time with a Logitech C170 streaming without h264 compression on a rt2088 USB Wifi dongle connected to an external USB powered Hub. It was solid problem at 640x480 over 30 fps. I have not experienced it with the RPI2 yet...
For (A) I think we want to stream both. I was planning on making the output from the video camera and the post-processed opencv stuff available as separate video streams over UDP. So the pilot would hopefully get a fast live video stream but then if they wanted to see what the computer sees they would use the slower updating post-opencv stream. We'd have to find some way to turn on/off the stream that's not being viewed (or massively reduce it's quality so i doesn't use much bandwidth).
For (B), it's mentioned above but I think it's whichever stream the pilot is looking at.. so the GCS will need to pass that info back to the companion computer. MAVLink has a MAV_CMD_DO_CONTROL_VIDEO message that might allow this.
ok, thanks buzz! the web page mentions "low-latency" and "0.4sec" in the same sentence. Not sure that qualifies as low-latency in the drone world but I'll give it a go in any case, thanks!
there's some good bits of information ( and instructions to run ) about video streaming and opencv in the 3dr developer docs.... not all of it applies to us as some of it's closed/proprietry, but much of it does.... http://dev.3dr.com/concept-video.html eg using '
v4l2loopback' , and http://dev.3dr.com/example-opencv.htmlThis will be a big time saver.
Please add Screen to the list if it's not already on there.
-
3
-
4
-
5
-
6
-
7
of 8 Next