Skip navigation
2015

Disclaimer: I’m an engineer, not a pro film maker. Be advised.

Disclaimer: I’m an engineer, not a pro film maker. Be advised.

 

Raspberry Pi cases are all the rage. Everyone makes blocky cases, wood cases, cases shaped like computers or arcade cabinets. I wanted a case that could interact with the physical space around it-- why not put a Raspberry Pi 2 in a ball?

 

Here are just a few things I can do now--

 

  • bowl with it
  • wirelessly connect to the Internet
  • draw in 3D space with motion tracing
  • automated bounce counting

 

Meet the Pi Ball!

 

Here were my requirements

- Use a Pi (Raspberry Pi 2 in the case)

- Spherical case, that can be bounced, kicked, thrown

- Accelerometer onboard to monitor the motion of the ball

- Wireless everything! Wireless keyboard/mouse, networking, sound and video

 

   pi ball glow and running.png

   (Pi Ball in on! LEDs on! Wirelessly connected to the screen in the background - running the accelerometer tracking program.)

 

Project by sections

 

The Pi Ball enclosure:

 

The Pi Ball spherical enclosure consists of three pieces. Two hemisphere and the mounting plate attached in the middle.

   pi ball 3d model.JPG

   (The 3D model of my concept. I used Solidworks 2013.)

 

I wanted a smooth external appearance. No screws/bolts holding it together.

 

   pi and enclosure pi ball.png

   (Here is the freshly printed enclosure components. A Pi 2 place on the mount plate for scale.)

 

   pi ball parts layout.png

   (Pi Ball parts layout. Had to stuff all that inside the enclosure!)

 

When the hemisphere lock together, they wedge the mounting plate in the middle. The hemispheres are made of “elasto-plastic” from Shapeways, and the mount plate is regular ridged ABS. The Elasto-plastic shells were quite bouncy – when empty. However, with all the components inside, the high bounce was gone.

 

   mount plate and pi2.png

   (The mount plate, Pi 2 attached using four M2.5 cap head bolts)

 

The middle mount plate has slots for passing wires and such, and the Pi is attached to the plate via standoffs printed on the surface. Those standoffs were tapped for M2.5 bolts.

 

   pi ball cable routing.png

   (Pi Ball, early Raspberry Pi 2 mount and wire routing.)

 

 

 

Wireless devices:

 

Making everything wireless turned out to be very easy with today’s tech. Wireless keyboard and mouse adapter was a single low profile USB transceiver. The WIFI adapter was exactly the same. The wireless HDMI comes via a Nyrius AERIES 1080p transmitter. (The HDMI receiver is attached to the screen. The one I used had a 165 foot line-of-sight range. But, I found that I could get about 90-100 feet without issue.)

 

   pi2 inside.png

 

To stay wireless, the devices need power. I used two onboard battery packs – for two different, but critical reasons.

 

ONE – The HDMI adapter needed 5V@ 1.5A, so to take the strain off the main battery I found a small 2200mAh external battery. Tool the enclosure off of it, and placed it on top. The Pi and the LEDs shared a 8400mAh external battery supplying 5V@ 2A.

 

TWO – The two separate batteries created a better balance inside the sphere. So, it rolled more like a ball than an egg.

 

   pi ball stack of parts.png

   (Almost everything attached to the mount plate. Pi2 on top with the HDMI transmitter and 2200mAh battery (not shown). Bottom has the 8400mAh battery, USB hub, and accelerometer (not shown) )

 

   neo pixel pi ball test.png

   (NeoPixels on, via their own power source.)

 

The Adafruit NeoPixel LED strip needed to source more power than the Pi 2 could supply. So, I connected them to their own USB cable connected to the 8400mAh battery directly. Only the signal life from the NeoPixels connected to the Pi 2 (pin 12 to be exact)

 

   closing up the pi ball.png

   (About to close up the Pi Ball...)

 

   pi ball on deck running.png

   (Pi Ball is on... running the accelerometer sensor program - wirelessly connected to that LG TV.)

 

 

Battery life:

 

    pi ball 2200mah batt.png

   (The 2200mAh battery removed from its red case. This way it was much smaller to put on top of the HDMI adapter.)

 

The HDMI adapter on the 2200mAh battery was what gave out first. It lasted 3 hours of constant streaming. I could have easily doubled that with another 2200mAh battery, there was room.


   anker 8400 strapped to back pi ball.png
   (Anker 8400mAh battery strapped to the back on the mount plate. An early step in the build.)

 

For the Pi 2 itself. the 8400mAh battery lasted about 12 hours of intermittent use. But, after 3 hours I did not have video output. That may have extended the life.

 

 

Software (all in Python):

Aside from running the full OS, where one could do regular computer work, tinkering, etc.. I had two specific Pi Ball applications.

 

- An on screen representation of the Pi Ball’s location and movement in an isometric representation on 3D space. It looks like a fading comet trail. I also put in a mode to trace the movement. My idea was for someone to hold the ball and draw in 3D. However, it only partially worked. I need to change it to take more samples.

 

- I also had a mode to count the # of impacts detected, like bouncing.

 

- The second feature was turning on LEDs inside the ball. The main feature was to react to the accelerometer data, and turn on, flash or chaser effects on one of those Adafruit Neopixel LED strips. This worked spotty at best. But, when it worked, it did what I wanted.

(I have an always on, always off, a constantly flashing/chasing, and accelerometer effected modes.)

 

 

The difficulties

 

- All the USB cables used inside the Pi Ball had copious amounts of rubber/plastic on the connector ends. I used a knife and shaved off the excess to make them more flexible and smaller.

 

   shave.png

    (Here is an example of cutting off wire thickness. This is the shaved HDMI cable. I also took some of the rubber shielding on the length to make it more flexible.)

 

- Fitting everything into the Spherical case. Perhaps if I make a version 2, I will up the size from 6” diameter to something like 8 or 10”. That way I could pack in more sensors and effects.

 

- Getting the Neopixels to work. Sometimes they would flash random colors or effects. They are  dependent on the frequency output of the Pi. I stuck with a white only color to just get it to work.

 

 

Schematic and Design

The only true schematic, is the accelerometer connection. See below:

 

accel adxl335_wiring.png

 

Everything else is just standards. IE, plug in mouse/keyboard to the USB port, etc

 

 

Code

(See attached to the post)

 

 

BOM

 

  

QuantityPriceVendorPart #Description
1$35$35element1468X0156Raspberry Pi 2
1$37.00$37.00element1445P6651ADXL335 accelerometer and parts kits
1$2.19$2.19element1419C7200ANALOG TO DIGITAL CONVERTER ADC
1$0.12$0.12element1498K49951N4001 diode
1$220.00$220.00ShapewaysNA3D printed components
1$48.00$48.00AmazonNALogitech wireless keyboard and mouse
1$8.00$8.00AmazonNAWiFi adapter (generic)
1$200-400(new)$200.00AmazonNANyrius wireless HDMI adapter (Pro model)
1$25.00$25.00Adafruit1461NeoPixel 60 LED strip
1$4.49$4.49AmazonNAJgmax 2200mAh external battery
1$19.00$19.00AmazonNAAnker 8400mAh external battery
TOTAL$598.80

 

Other uses of the system

 

Aside from having a completly wireless Raspberry Pi 2 system, the Pi Ball could be used for any number of applications - Imagination is the limit.

 

- In its current form, it can be used for motion tracking.

- I have a mode that lets the user draw in 3D space, tracing the motion.

- Count the number of bounces.

- Any number of light based effects.

- Roll it in, let the fun begin! Use your imagination...

 

When I have more time, money, or people really like the Pi Ball

- Source cheaper components. For instance, the accelerometer. The Wireless HDMI adapter could be bought elsewhere. The 3D printing could happen in house.

- Make a new version with more internal hooks. I designed in only 4 attachment points between the two hemispheres. I would want to increase that to at least 6.

- Better battery design and mounting.

- Bouncier all around. I want to bounce it like a basketball, personally.

- More software and code to use the ball to the utmost.

I decided to add my temperature sensor to my new Pi2. This is fairly straightforward - you need the following

 

 

Wiring it up

 

The DS18B20 sensor has three pins which are connected as follows. Note that the sensor has a domed side and a flat side - make sure you have it the right way round (i.e. flat side towards the pi in the breadboard setup shown below).

  • Pin 1 connects to GND
  • Pin 2 connects to GPIO4 on the Raspberry Pi
  • Pin 3 connects to the 3.3V supply (3V3) from the Pi

9007174784_bedf089720_z.jpg

 

This is connected to the Pi as follows. Do this with the Pi turned off!

 

9007174966_457a6eb01e_z.jpg

 

Coding

If you are using one of the 'new' Pis (i.e. the Pi 2), you will need to add the following line to file /boot/config.txt. If you don't do this then the temperature sensor wont be detected by the Pi.

 

  • Open the file for editing

 

sudo nano /boot/config.txt

 

  • Add the following to the end of the file

 

# Added to get temperature sensor working
dtoverlay=w1-gpio

 

  • Use Ctrl-X to save the file

 

Log on to the Pi and enter the following commands

 

sudo modprobe w1-gpio
sudo modprobe w1-therm
cd /sys/bus/w1/devices
ls -l

 

The final command above lists the content of directory /sys/bus/w1devices - you will see something similar to the following.

 

temp1.png

Note that there is a directory consisting of numbers - i.e. 28-00000521fad0 in the example above. This is the unique directory for the temperature sensor and is the serial number of the sensor you have used. Make a note of this as you will need tit when accessing the sensor.

 

Reading the temperature

Cd to the directory that you noted above and then run command cat w1_slave. This will interrogate the sensor and display the output - e.g.

temp1.png

Note that the temperature is displays in Celcius to 3 decimal places - e.g. in the example above t=23500, so temperature is 23.5 Celcius.

3DRacers race in progress (via Marco D'Alia & indigogo)

 

If you’re a fan of video racing games, such as the all-time favorite Mario Kart, you may freak for 3DRacers. The company takes competitive racing from the screen to your living room floor through 3D printing, microcontrollers and your smartphone.

 

The new concept allows users to make their own 3D-printed cars that can be controlled via Bluetooth through their phones and then race with friends on carpet or an optional race track. The cars can be designed online by customizing one of 100,000-plus designs available online, including a Delorean, Monster Truck and Dune Buggy. Users familiar with 3D-printing software can also create their own car designs from scratch using the company’s open-source template.

 

toycar2.jpg

3DRacers’ Delorean car prototype (via Marco D'Alia & indigogo)

 

Once the design is printed (which can be done at home or through the company’s partner store, 3D Hubs), it’s time to build. The cars are powered by open-sourced Arduino-based circuit boards, ATMEGA3244 microcontroller and 3.3V regulator. It is also programmable via USB connectivity. The board equips the car with RGB LED lighting, two motors, three servomechanisms, infrared capability and a detector that knows when its at the starting and finish lines. It runs on a rechargeable lipo battery (rechargeable via USB) and can race for 30 minutes per charge.

 

toycar3.jpg

3DRacers PVC Mat (via Marco D'Alia & indigogo)

 

Once the car is built, the only thing left to do is race! 3DRacers claims the cars will drive on any surface, but a custom 4x8.5ft PVC racing mat can be purchased for an authentic racing feel. The track includes papercraft models, such as trees and oil barrels, to simulate 3D structures that would be found on an authentic racing arena. Users can control their cars with a 3D-printed remote or from their smartphones using the compatible iOS and Android app.

 

toycar4.jpg

3DRacers car prototypes and iOS app interface (via Marco D'Alia & indigogo)

 

As far as racing logistics go, 3DRacers says up to 1,000 players can race at once, and the app recognizes various racing games. The technology with automatically keep tabs on laps and the scoreboard, and also simulates professional racing, in that drivers can stop for pit stops and practice with warm-ups. If road rage is your thing, however, you can play in battle mode, when you gain points by destroying your opponent’s car (virtually). This mode also features a turbo option and power-ups that include virtual weapons. Move over Mario Kart.

 

3DRacers will be coming to a 3D printer near you, as it’s Indiegogo campaign was fully funded. There is still a full week left in its campaign, so if you’re looking to be one of the first to take your custom car for a test spin, or if you want a break on the price, order now. The bare bones kit, which gives you everything you need to design and print your car at home, is on early bird special for $39. If you want the racetrack mat, that’ll set you back another $129, not including the pilot board and other important parts. The first batch of Beta boards are set to ship by May.

 

C

See more news at:

http://twitter.com/Cabe_Atwell

Pi2ModB1GB_-comp-500x283.jpeg

This is the Raspberry Pi 2, which I used to calculate pi against other Pis. (Image via Raspberry Pi)


I received a Raspberry Pi 2, and immediately wanted to see how much of an improvement it was. Games seem smoother, especially first person shooters. Arcade emulation is buttery as well, however perceived speed wasn’t scientific enough for me so I decided it would be apt to calculate Pi, on the Pi.

 

To start with, I installed the Command Line Calculator, called BC

 

Easy to install… type at the command prompt:  sudo apt-get install bc

 

To calculate pi, I used the command line formula:  time echo "scale=2015; 4*a(1)" | bc -l

 

Scale is the number of decimal places to calculate. The a() portion is the Arc Tangent function. Obviously, the bc part is the bc utility.

 

The results for the three Pi models (original B, B+, and Pi 2), at stock clock frequency, were as follows (results in seconds):

 

Model B

Real  0m24.996s

User 0m24.660s

Sys 0m0.260s

 

Model B+

Real  0m24.940s

User 0m24.620s

Sys 0m0.250s

 

Pi 2

Real  0m15.575s

User 0m15.470s

Sys 0m0.090s

 

The model B and B+ results were the same, which isn’t surprising since the boards are almost identical. Unsurprisingly, added RAM has no influence on this simple calculation. Also, I ran the calculation several times and found the results varied, which was surprising.

 

The Pi2 had a 62% improvement in time over its predecessors. As it turns out, that the bc calculation was a single thread operation, and only one core is used, however the Pi2 beat it predecessors by 9.085 seconds with 3 cores tied behind its back.

 

I could extrapolate that if the load was shared across the cores, the Pi2 could calculate Pi in 3.8938 seconds. Which is about 155% improvement over the original Pi models. However, that is just a hypothesis.

 

To discover more about taxing all the cores in a benchmark, I discovered the following benchmark results.

 

Looking at the MP-MFLOPS

 

Using Roy Longbottom’s Android multithreading benchmark MP-MFLOPS, it’s clear that the Pi2 is noticeably faster, especially when it’s overclocked to the maximum @ 1,000MHz. Of course, this is with using all 4 cores of the ARM Cortex-A7 running 8 threads (2 Hyperthreads per-core) running 2 operations per-word and 32 respectively. The benchmark for the old RPi (single-core running @ 700MHz) achieved 43 MFLOPS @ 12.8 loops running 2 Ops/Word and 191 MFLOPS @ 12.8 loops running 32 Ops/Word respectively.

 

You will no doubt notice the difference in speed with the Pi2 and the use of all 4 of its cores utilizing 8 threads (higher numbers are better). The Pi2 clocked @ 900MHz came in with 494 MFLOPS @ 12.8 loops running 2 Ops/Word and 1581 @ 12.8 loops running 32 Ops/Word respectively. Crank the processor up to 1000MHz ups those numbers to 543 and 1588 @12.8 loops, making it considerably faster over the original Pi.

 

On 2 Ops/Word, the Pi2 (all 4 cores) is 1148% faster than the original. At 32 Ops/Word, the Pi2 (all cores) was approximately 83% faster and the original Pi B.

 

pi bench.JPGpi2 bench.JPG

Benchmarking the MFLOPS (via Roylongbottom)

 

MP-MFLOPS isn’t the only benchmarking tool that can be had for the Pi2 platform as Raspberry Pi blog user Dan Robinson benched the new board against the B+ using the SunSpider JavaScript tool to clock his speed. The app suite from Webkit runs JavaScript to measure real-world performance such as encryption and text manipulation, making it ideal for measuring the performance for web browsers as well as the Pi2. After benchmarking his board using SunSpider, Dan’s results were interesting to say the least with 4452.1ms for the Pi2 and a shocking 23692.7ms for the B+ (lower numbers are better). To put that into perspective, another blog user Martin O’Hanlon makes it easy to understand those differences sating ‘Minecraft server on a Pi1 = adequate, Minecraft server on a Pi2 = awesome’.

 

octane.png

Google’s Octane 2.0 is just one of the few tools that users can use to benchmark the Pi2.

 


Another benchmark I found was was about video transcoding, done by Andrew Oakley on Raspberrypi.org. His results:

Transcoding Skinny Puppy’s “Pro-Test”, 360×270 Quicktime .MOV, 256kbps MP3, to same resolution MP4 at CRF 26, 96kbps, using avconv:

Raspberry Pi 1 (1x 700MHz ARMv6, 512MB RAM, Raspbian Wheezy): Average 1 frame per second. 18 mins to complete.

Raspberry Pi 2 (4x 900MHz ARMv7, 1GB RAM, Raspbian Wheezy): 28 FPS, 4 min 9 secs to complete –

Intel Celeron dual-core (2x 2.5GHz 686, 2GB RAM, Ubuntu Precise): 114 FPS, 1 min 3 secs

 

You can see the Pi 2 is getting results close to desktop processors. There are plenty of other benchmark tools on the internet that can be used to measure the performance of the Pi2, including Nbench, Google Octane and Unixbench as well as a host of others. After looking at some of those it becomes quite clear that the Raspberry Pi 2 is more of a desktop PC than a mere development board, which is certainly the case when it comes to the performance of the original Pi and even the B+.

 

C

See more news at:

http://twitter.com/Cabe_Atwell

Note: XMP-2 also has a virtual simulation, check it out by clicking here.

 

Introduction

The ground-breaking XMOS startKITXMOS startKIT is an ultra-low cost near-credit-card sized board designed for real time operations. It was launched about a year ago at a very low cost (£12 including VAT) as a processor board intended to connect to the Raspberry Pi and XMOS went on to distribute thousands of startKITs for free.

 

Together with the Raspberry Pi one of the boards was used to create a robot called XMP (XMOS Mobile Platform). Version 1 of the robot was quite primitive and really just a proof-of-concept type of project.

The brand new XMP-2 robot was made possible thanks to another startKIT from john_xmos at XMOS and a Raspberry Pi courtesy of doctorcdf at Element14. Here it is at the Element14 stand at Embedded World 2015 in Germany, manned by an Imperial Stormtrooper (click here to see a video of it in motion – 1:40 into the video):

robot-front.jpg

 

XMP-2 is not complete yet (it is a 1-month old baby yet has already turned to the dark side) and is currently missing sensors and will eventually have a custom PCB too. Distance measurement will be based on a camera and laser arrangement.

 

It was built in a few evenings due to needing to be shipped to Germany quickly. It relies heavily on Lego for the electronics attachments. However the chassis, wheels, ball rollers and axles are constructed from aluminium and steel for a rigid and reusable base for experiments.

robot-part-assembled2.jpg

 

Circuit Overview

The diagram below shows the main components used; click to enlarge.

xmp-2-overview-diag-2.png

 

XMP-1 relied on continuous rotation hobby servos which are fairly inaccurate. XMP-2 uses brushed DC motors and Infineon H-bridges to power them. All motor control occurs using the XMOS xCORE processor. For closed loop feedback encoders are used. These are connected to the XMOS board so that the xCORE processor can count pulses (tens of thousands of pulses per second - around 60k pulses per wheel revolution in this design) as the motor turns, calculate appropriate pulse width modulation (PWM) which then drives the motors through the Infineon H-bridgesInfineon H-bridges. The closed loop feedback means that the robot can make movements with accuracy and allows for motion even at slow speeds where open-loop PWM in ineffective as soon as the motor encounters a load. For more detail on closed-loop PWM and control of brushed motors, check out this post which used a BeagleBone Black for controlling motors. To get a basic understanding of different motor types click here. There is also a post on the Infineon DC motor control H-bridge boards which were used.

Click here for a video showing a practice run of just the motor control portion (before the robot was complete).

practice-run2.jpg

 

XMP-1 required two power sources. This time round a single battery source (initially non-rechargeable batteries) is used to power everything. To further simplify things, a custom PCB will be created at some point to replace the mass of wires and also provide a rechargeable battery solution.

 

The entire robot (including motors, XMOS board and Raspberry Pi) is powered using six AAA batteries.

 

The XMOS board was used to control the motors while relying on feedback from the encoders. Another aim is to eventually implement a vision system to be able to navigate around objects autonomously.

 

Mechanical Overview

A classic differentially steered design was created with two wheels that are driven by the motors and the speed and motor direction can be controlled. The third wheel (unpowered) was actually a ‘ball transfer unit’ (from Alwayse Engineering,  model 7101) which is a bit like an old computer mouse ball but usually operated in the inverted position for conveyer type systems. Another ball transfer unit was used for stability and becomes the fourth wheel.

 

The motor unit has built-in gearing and a built-in encoder – it is available new from Faulhaber (Series 1524..SR) and is also available in used/repaired condition via eBay from several sellers. It is further geared down using a gear from motionco – primarily to decouple the motor unit from the output shaft for reliability but also to reduce the motor speed and increase the torque. Everything is held together using a motor/gear assembly block made from plastic. To build something similar schools/colleges may have a machine shop or a 3D printer and accurate drill press could be used (sub-millimeter accuracy is needed to mesh the gears properly). Don’t forget to wear eye protection.

 

The slide show below shows the motor/gear assembly block construction and how it was fitted to the chassis. The wheel shaft and bearings were from motionco too. It was decided to have a 4mm diameter output shaft to the wheels. The chassis is built using aluminium extrusions (available from eBay) with rounded edges – far safer than the XMP-1 design.

{gallery:autoplay=false} Motor/Gear Assembly Block Construction

motor-mount-annotated.jpg

Assembling the block: The motor can be seen inserted at the right

motor-mount2-annotated.jpg

Mounting the motor: The motor fits into a part-bored hole and is secured with two small bolts. There is a small recess for fitting a bearing for the axle

nuts-bolts.jpg

Attachment to chassis: The center hole shown here is bored to two diameters, one for passing the axle through, and the larger diameter is for fitting another bearing

gear-and-hole.jpg

Axle and Gear: The gear is glued to the shaft

The photo below shows the assembled chassis with the motor/gearbox blocks mounted, a ball transfer unit and lenseslenses and laser.

chassis-motors-mounted-rr.jpg

 

Engineering Drawings

If you’re building a replica and intend to closely follow the design, then the slideshow below contains the detail on how to construct the motor/gearbox mount and chassis:

{gallery:autoplay=false} Engineering Drawings

gearbox-design-2.png

Motor/Gearbox Block: Poor diagram but it gets the point across hopefully; dimensions from the rear of the block

gearbox-design-1.png

Motor/Gearbox Block: View from side

gearbox-layout.png

Motor/Gearbox Block Assembly: How the bits fit together

chassis-layout.png

Assembly: This photo shows how the motor/gearbox block, axle and chassis fit together

Lego Integration

Lego was instrumental to mounting most of the electronics. It allowed the design to be implemented quicker without needing to worry upfront where precisely all the boards would be mounted. The photo below shows how the XMOS startKIT was mounted. Two white 4x1 blocks were drilled and screws were used to secure the XMOS board to them. In the photo below, the stripboard on the left contains all the power supply circuitry.

xmos-board-annotated.jpg

 

The stripboard and the Infineon boards were also mounted using Lego; they were glued into notches cut in Lego as shown in the photo below:

inf-motor-changed-cap.jpg

 

Putting it all Together

The slideshow below shows what the robot looks like from various angles (laser and headlights powered up in some of the photos):

{gallery:autoplay=false} XMP-2

robot-front.jpg

Front View: Laser powered up

robot-front-zoomed.jpg

Front View Closeup: Stormtrooper keeping watch

robot-rear.jpg

Rear View: The XMOS startKIT can be seen here. It has a 3x3 matrix of LEDs which could be used for status/notifications

robot-side.jpg

Side View: 'Micromouse' style wheels were used

robot-front-lit.jpg

Front View: Headlights lit up!

The XMOS board can be seen close-up below:

robot-detail-xmos-annotated.jpg

 

The Raspberry Pi can be seen installed in the photo below:

robot-detail-rpi.jpg

 

Another photo of the power supply board:

robot-detail-supply.jpg

 

Schematics and Source Code

There really isn’t a lot to the schematic currently that cannot be deciphered from the circuit overview shown earlier in this post. As soon as a schematic is created, it will be published here. Meanwhile, for any technical questions regarding the circuit, please ask in the comments section below. No schematic was created because of the very rapid prototyping that occurred for this project (any parts used were just thrown onto the stripboard!).

 

The source code will be published once tidied up (this might not happen for a while – please ask if you need the raw code, I’ll be happy to share it). A similar scheme was followed as for XMP-1, where the Raspberry Pi implements a web server and the XMOS board implements all motor control.

 

There is a three-part guide to the XMOS startKIT that hopefully helps understand how to use it. Part 1 is a general guide to the startKIT for newcomers. Part 2 covers the serial peripheral interface (SPI) communication between the Raspberry Pi and startKIT. Part 3 provides another SPI example amongst other things.

 

Update January 2016 - Detail Photos

Here are some more photos of the circuitry. A DC-DC converter DC-DC converter was used to provide 5V for the processor boards. It is the box-shaped component in the photos. A small 3.3V LDO regulator3.3V LDO regulator was used to power some logic gates for the rotary encoders. The power switch can also be seen soldered onto the stripboard above the DC-DC converter. Red dot indicates powered on position!

xmp-2-vero-front.jpg

 

Another view. A few electrolytic capacitors are used as recommended by the DC-DC converter and LDO datasheets. A few ceramic caps are on the underside (not shown).

xmp-2-vero-front-view-2.jpg

 

The wiring may look messy but it was mostly color-co-ordinated and easy to follow. Notice the XMOS StartKit has had header pins soldered on the rear of the PCB, not the front side, for ease of assembly (and I wanted the LED array on the XMOS StartKit to face the other side).

The red Infineon boards can be seen glued into notches cut in the white Lego pieces. The StartKit was bolted using holes drilled in Lego, so it is easily removable.

xmp-2-angle.jpg

Side view. The large electrolytic capacitor that is present on the Infineon boards by default was reduced in value due to the low current requirement of the motors that were used.

infineon-view-xmp-2.jpg

 

Laser Ranging

The photos below show the principle that could be used for laser ranging.

The first photo here shows the default view against an example (cardboard) wall. The laser beams a line pattern (it has a special lens to do this):

xmp-2-laser-action.jpg

This next photo shows what occurs when a Stormtrooper is positioned between the laser and the wall. Notice the horizontal laser projected line has been cut, and is reflecting off the Stormtrooper:

xmp-2-laser-action-example.jpg

From the height difference between the horizontal line off the background wall and the reflected line off the Stormtrooper, it is possible to deduce that an obstacle (the stormtrooper) exists, and the deduction can be done with very little image processing needed.

laser-ranging-height-annotated.jpg


What’s Next?

XMP-3 will be next. It will reuse the same base as XMP-2, but will have increased functionality – primarily a robot arm – and will use a PCB to replace the stripboard (and will therefore have a schematic).

 

Summary

XMP-2 is a completely new robot, very different from the XMP-1 prototype. It has fairly accurate motion thanks to closed loop control and is therefore a suitable platform for attaching sensors and vision. The XMOS startKIT was key to monitoring thousands of pulses per second from both motors and using them to control the motor motion. The Infineon H-bridges, although overkill for this particular robot, were selected so that the robot could be scaled to larger sizes easily without needing many schematic modifications.

 

The base will serve as a suitable platform for XMP-3 - stay tuned!

 

xmp-2-laser-darth-vader.jpg

Today we’ll be creating a remote controlled satellite weather station using a Raspberry Pi, a temperature sensor and a RockBLOCK. The envisioned application would be a weather station in a really remote location (i.e. outside of mobile/cellular coverage) – maybe in the middle of the desert, the jungle, or even the arctic – sending its data back to some kind of central weather system.

We’ll keep it really simple, using just one temperature sensor, but additional sensors could be added very easily to expand the scope – to measure humidity, atmospheric pressure or light levels. The temperature sensor used is a Maxim DS18B20 digital thermometer which provides a reasonably accurate reading (+/- 0.5 degrees) over a wide temperature range (-55 to +125C)

The weather station application will periodically transmit its sensor readings using the RockBLOCK. For those of you who don’t know the RockBLOCK, it’s an awesome little module that enables small amounts of data to be sent/received via satellite from anywhere in the world. Ideal for creating all manor of remotely deployed projects, like the weather station! We’ll be utilising the excellent pyRockBlock library (excellent, because it’s written by me!) to take care communicating with the satellites via the RockBLOCK.

The temperature sensor selected operates on the 1-Wire bus, which means it can be connected directly into the GPIO pins on the RPi, and with a little bit of configuration, can very easily be interrogated by Python – without the need for any additional electronics!

You can view the full project over at Makersnake.com (Remote Controlled Weather Station).

Image7.jpgImage19.jpgImage18.jpgImage23.jpgImage26.jpgImage27.jpgImage32.jpgImage34.jpg

Filled with poor judgement, and delight!

Filter Blog

By date: By tag: