Hey folks, We’re interested in doing a few more demonstration projects with the BrickPi. I wanted to reach out to our community and ask:
What should we do next?
If you look at the different projects we have, hopefully you see we’ve been trying to build a basis for understanding how the BrickPi works, and what you can do with it. Maybe there’s something we’re missing that demonstrates a feature or an ability of the BrickPi? If you have any ideas, please shout it out!
I do have some ideas for projects (everybody should build a segway at least once in their lives 
). However, when looking through the available code I noticed that the programming interface is currently fairly low level. Basically one is programming directly to the driver code. Not a problem for small programs, but error prone for larger or more complicated ones.
Specifically the driver code for reading sensors is not thread-safe. So a programmer who wants to use multiple threads of execution (e.g. one for balancing a segway and one for other stuff) needs to make sure that setting up the sensor structures and calls to BrickPiSetupSensors() and BrickPiUpdateValues() are not executed simultaneously in two or more threads.
I think it would be nice to have a higher level api available that handles this kind of problems automatically. I have some ideas of how to set this up and want to help implement it, but perhaps it is better to first have some discussion about the desired architecture for such an api.
An example scratch program with motors and sensors working together. Robot following a line or robot that avoids hitting thinks using ultrasound 
Adding to Frans comments it would be nice if someone did the fusion software to merge the accelerometer and gyro sensor data of the dIMU: Inertial Motion Sensor. Ideally this would be done on the BrickPi Arduino, probably based on the FreeIMU library created by the late Fabio Varesano. This is the code used in many quadcopters. Flying a quadcopter is a similar problem to driving a Segway. Applications really want to treat those sensors as one sensor with the gyro providing quick response and the accelerometer compensating for gyro drift. Once fusion data is available a balancing Segway type robot is pretty simple to implement. If it was done on the Arduino it would reduce some of the multithreading problems Frans mentioned. Also sensor fusion really wants to be done in real time which is basically the Arduino’s job.
Note FreeIMU library can also merge 3D compass data which is valuable. I rather wish the dIMU was based in FreeIMU hardware which gives you 10 DOF on a single board covering the above three sensors plus barometric pressure for altitude. Robot software shouldn’t really have to treat these as different sensors. We’re not too far away from being being able to buy the set in a single chip that tells you everything you want to know about where you are headed and how fast. That’s where the market is going, mostly driven by smart phones. Meanwhile standard software should be available to hide the messy details from the regular user. The problem has been solved and is available open source.
Another useful project might be to address how to web connect even if there is no wifi available. It would be nice to carry a BrickPi bot and your smartphone somewhere with no available wifi and still be able to connect them. For example it would be fun to bring my bot to work where they don’t allow foreign devices (including our iPhones) to use the local wifi. I’m sure that the raspberry pi can be configured as a wifi access point. It is probably just a matter of editing some network configuration files. It would be handy if such functionality was built into the BrickPi wheezy image.
I’d be tempted to use this as the standard mode even for development because it would make me always independent of existing wifi. That might need two wifi connections though, one to get outside (for code updates etc) and the other for local connections for control purposes. I guess this would mean two wifi dongles. Hmm. Might be more complex than I thought.
just a thought.
OK the solution is set up Raspberry PI is wifi access point using hostapd and dnsmasq. Note. This is only needed if there is no wifi you can log into. It lets the rPI be the hotspot. There are lots of posts searchable on google telling how.
Also there is a great python interpreter for the iPhone called pythonista.It has full internet access plus lots of access to the phone capabilities, accelerometers, draw pretty pictures on the screen. An iPhone python script can:
iPhone programming just reached a whole new level. After buying pythonista I wrote a simple accelerometer interface script that drew a picture on the screen that always pointed up no matter how you tilted the phone, in about 10 lines of python code.
I have recently completed the browser controlled robot.
I also simultaneously activated a live video stream from the rpi camera module using netcat.
I am having a difficult time understanding the code as I am very new to python programming (I’ve only completed the Python track on Codecademy).
What I would really love to see is:::
Guidance on how to best document their projects and build progress. Where/How do you suggest we display our work? (ie do you recommend instructables? setting up a blog? have a series of youtube videos? or a personalized area within the brickpi forum?). Best practice for how to document a build would be great for beginners!
A project example that shows how the user can extract a encoder counter from the code to measure distance travelled (accurately) and display that on the web browser socket. (every robot’s wheel diameter will vary of course).
An RPi Camera module interface project would be awesome, especially if it utilized the python camera interface created by Dave Jones (http://picamera.readthedocs.org/en/release-1.6/). Is netcat or ffmpeg the best for streaming?
An incentive system to encourage dormant BrickPi community members to start posting on the forum. like have “bite sized” tests that the community could perform in return for some kind of reward/recognition (preference going to those who followed documentation and testing best practice). This could foster a collective effort over time so future users could leverage off the previous tests performed.
A wifi direct project (as suggested by zencuke) would be awesome also.
Theses are merely my suggestions (apologies for my ramblings) and I appreciate that these are easier said than done. Examples on the main page are awesome keep it up!
This is my first post in the forum