Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

First MVP #34

Closed
tdurand opened this issue Dec 8, 2017 · 7 comments
Closed

First MVP #34

tdurand opened this issue Dec 8, 2017 · 7 comments
Assignees

Comments

@tdurand
Copy link
Member

tdurand commented Dec 8, 2017

We do have a first very rough MVP , it feels Christmas 馃巹!

Documentation

Worked a lot on that end, please review the readme: https://github.com/moovel/lab-traffic-cam/blob/master/README.md , normally if someones go threw all the steps he should be able to run the MVP, but I may have forgotten some steps, so could be great that someone tries to install it while I'm off to get a first feedback on that.

Also there is a lots of step that we need to work on automating, I'm not really devops as you know @b-g so maybe it could be great to reserve a slot of someone inside/outsite moovel and have him helping us on that end.

Technically wise, better than hundreds words, I've put together that schema of the architecture:

technical architecture open traffic cam

Limitations and next steps

This is when you see the christmas gift isn't that great yet 馃榿.

UI

Really "minimal" UI for now, you have 2 screens:

screen shot 2017-12-08 at 11 44 46

screen shot 2017-12-08 at 11 45 24

And then you have some debug info that are ouputed on the console of the jetson (you see 1 FPS now because I haven't overclocked the jetson on those test)

screen shot 2017-12-08 at 11 45 55

Tracker accuracy

For now as we haven't implemented the UI to defined "counting areas", we are doing only the following logic: "Count everything that have been matched for more than 3 frames." (but obviouly each time the ids get reassigned for the same object, we will count it twice...)

Bugs

The UI doesn't take in account the "async" nature of the processes, the main bug is when you click on start counting, the UI display immediatly the counting screen, but as YOLO takes 30s to startup, if you click on stop counting, it will failed miserably and leave a child process that will leads you either to restart ubuntu or to kill the process manually with ls -ef;kill -15 PROCESS_ID

Also it's very possible that the process cannot start / stop well for some other reason, it's very rough yet.

Next steps

  • Implement the counting lines Editor UI to be able to count stuff better
  • I think it actually may be helpfull to display the bounding boxes of the yolo detections on the counting screen, we can't display the webcam stream but we could draw the bounding boxes, maybe some rethinking to have for the design here.
  • Then refine with the actual colors and real style. @mmmmmmmmmmmmmmmm actually in January if you have time, you could start an empty next.js project and work on implementing some react components with styling independently from the jetson / Yolo logic (like buttons, fonts, static screens), would be really helpfull to speed up in February.
  • Work on devops to have a seemless install process that just start the node app when the jetson starts.
  • Making it way more robust at starting / killing process...
@tdurand
Copy link
Member Author

tdurand commented Jan 29, 2018

@b-g Ping on this, I think I could use help of someone that knows about doing a "Packaged" installation of Ubuntu with things pre-installed, pre-configured. It would save me lots of time. It not I can research and do it, but let me know. If you have someone, the README is already pretty complete on installation step, I guess the task would be to go through it and work on automatizing the install process.

@b-g
Copy link
Member

b-g commented Jan 29, 2018

@tdurand MESO said that they would help with making the yolo more ship-able on ubuntu ... Maybe we simply extend then their eg. chef recipe? Can you file an issue on the meso yolo repo and cc me?

@tdurand
Copy link
Member Author

tdurand commented Jan 29, 2018

This would be only for the step 4 of the README of the installation of yolo : https://github.com/moovel/lab-traffic-cam#4-download-and-install-the-yolo-darknet-net-mesos-fork ?

@tdurand
Copy link
Member Author

tdurand commented Jan 29, 2018

I created an issue: meso-unimpressed/darknet-net#5 , I guess what my previous comment meant was that automating the YOLO mesos fork installation is one step of the whole process of installing lab-traffic-cam on a jetson (need to config the Wifi hotspot .... ) so If someone has some skills in dev-ops we could still use his / her help 馃槈

I'm not really sure how automated it should be, as anyway people need to have a Jetson, so I guess they now how to run a set of commands on it, maybe just reducing the amount of steps.

@b-g
Copy link
Member

b-g commented Jan 30, 2018

@tdurand I see!
@florianporada Could you help with this? The task would be to find a way to automated the setup of the jetson in a very pragmatic way e.g. image, chef cookbook, bash setup script etc. See https://github.com/moovel/lab-traffic-cam#-step-by-step-install-guide

@tdurand
Copy link
Member Author

tdurand commented Jan 30, 2018

I guess right now the most painfull step is the Wifi hotspot set-up.. Also I mentionned on the README that it would be nice to set-up an automatic redirection to the node app like the wifi hotspots in airports hehe, but I didn't research on how to do that.

PS: For the setup of the node.js app itself (Step 5), maybe something like this https://github.com/zeit/pkg can be usefull, it's from the same guys as next.js.

@tdurand
Copy link
Member Author

tdurand commented Feb 9, 2018

Closing, moving to next step: #35

@tdurand tdurand closed this as completed Feb 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants