Live data from Hacker News

Show HN: Self-Driving Pi Car

github.com

31–40 of 49 posts

Re: Show HN: Self-Driving Pi Car

#31
post #5

Awesome project, but why Python 2? :( Pre-compiled Python wheels are available for Python 3 on Raspberry Pi at piwheels.org (default for pip in Raspbian)

I'm tired of seeing this comment over and over on HN. Does everyone who writes a Python 2-based project on HN have to explain themselves and provide a valid excuse? Why can't people just be deciding they like Python 2 more than 3, or finding that it's more suitable for their project?

I'm sorry it's getting tedious (and I agree, it is), but yes, at this point you do need a good reason for staying on Python 2, and in this case, learning about their good reason is actually helpful and insightful into their choices.

This wasn't contentious or combative (I didn't interpret it as such anyway), it's a good question for new projects.

Re: Show HN: Self-Driving Pi Car

#37

Any company doing this to solve the scooter littering issue? Like a Self Driving Scooter that drives itself back home?

Are there any guides on extracting the electronics, or batteries out for personal uses?

I hear there is a whole black market for electric scooter batteries.

Re: Show HN: Self-Driving Pi Car

#38
post #36

So all of the training was done without a GPU?

Elaborating on my question.

In your read me it says - "In the computer that you will perform the training -- protip: don't train the model in the Raspberry Pi! -- install all the requirements by runnig:"

Could you give some specs on the computer? I currently don't own a GPU based PC so was wondering if I need to get one or use cloud based GPU instance.

Re: Show HN: Self-Driving Pi Car

#40
I built something similar for my senior design project. We made a game of Pacman using two little rovers running FreeRTOS with RN-131C wifi modules on a PIC board and an overhead PixyCam connected to a raspberry pi. The rovers had a color sensor on the front and back that would allow it to track a black line on white paper. The overhead camera would feed pacman and ghost positions to the identical rovers. The rovers were commanded by just telling it what to do at the next intersection and what speed to move at. We did most of the heavy lifting on the raspberry pi simply because it's quicker to write A* in python than FreeRTOS C. Once pacman was seen driving over a colored dot on the map, the ghost would be commanded to run from pacman. If the camera saw the two rovers touch, the game was over.

Modularity was pretty key on reducing the work for that project. The rovers ran identical code and had no knowledge whether they were a ghost or pacman. The command router didn't care if the instructions it received came from a AI or a user GUI.

The platform was limited by what the professor provided us. We only bought color sensor arrays. Other teams went with simpler "games" but much more complex sensor processing on the rover. Those teams had much more trouble getting their designs to work, essentially needing two separate code bases.

Half of us were taking a class on AI and the other half were taking network application design so the idea for the game seemed like an easy way to just reuse code from those classes.

Post reply on HN