It’s become a tradition that we follow each Raspberry Pi model with a system-on-module variant based on the same core silicon. Raspberry Pi 1 gave rise to the original Compute Module in 2014; Raspberry Pi 3 and 3+ were followed by Compute Module 3 and 3+ in 2017 and 2019 respectively. Only Raspberry Pi 2, our shortest-lived flagship product at just thirteen months, escaped the Compute Module treatment.

It’s been sixteen months since we unleashed Raspberry Pi 4 on the world, and today we’re announcing the launch of Compute Module 4, starting from $25.

Over half of the seven million Raspberry Pi units we sell each year go into industrial and commercial applications, from digital signage to thin clients to process automation. Many of these applications use the familiar single-board Raspberry Pi, but for users who want a more compact or custom form factor, or on-board eMMC storage, Compute Module products provide a simple way to move from a Raspberry Pi-based prototype to volume production.

A step change in performance

Built on the same 64-bit quad-core BCM2711 application processor as Raspberry Pi 4, our Compute Module 4 delivers a step change in performance over its predecessors: faster CPU cores, better multimedia, more interfacing capabilities, and, for the first time, a choice of RAM densities and a wireless connectivity option.

You can find detailed specs here, but let’s run through the highlights:

• 1.5GHz quad-core 64-bit ARM Cortex-A72 CPU
• VideoCore VI graphics, supporting OpenGL ES 3.x
• 4Kp60 hardware decode of H.265 (HEVC) video
• 1080p60 hardware decode, and 1080p30 hardware encode of H.264 (AVC) video
• Dual HDMI interfaces, at resolutions up to 4K
• Single-lane PCI Express 2.0 interface
• Dual MIPI DSI display, and dual MIPI CSI-2 camera interfaces
• 1GB, 2GB, 4GB or 8GB LPDDR4-3200 SDRAM
• Optional 8GB, 16GB or 32GB eMMC Flash storage
• Optional 2.4GHz and 5GHz IEEE 802.11b/g/n/ac wireless LAN and Bluetooth 5.0
• Gigabit Ethernet PHY with IEEE 1588 support
• 28 GPIO pins, with up to 6 × UART, 6 × I2C and 5 × SPI

New, more compact form factor

Compute Module 4 introduces a brand new form factor, and a compatibility break with earlier Compute Modules. Where previous modules adopted the JEDEC DDR2 SODIMM mechanical standard, with I/O signals on an edge connector, we now bring I/O signals to two high-density perpendicular connectors (one for power and low-speed interfaces, and one for high-speed interfaces).

This significantly reduces the overall footprint of the module on its carrier board, letting you achieve smaller form factors for your products.

32 variants

With four RAM options, four Flash options, and optional wireless connectivity, we have a total of 32 variants, with prices ranging from $25 (for the 1GB RAM, Lite, no wireless variant) to $90 (for the 8GB RAM, 32GB Flash, wireless variant).

We’re very pleased that the four variants with 1GB RAM and no wireless keep the same price points ($25, $30, $35, and $40) as their Compute Module 3+ equivalents: once again, we’ve managed to pack a lot more performance into the platform without increasing the price.

You can find the full price list in the Compute Module 4 product brief.

Compute Module 4 IO Board

To help you get started with Compute Module 4, we are also launching an updated IO Board. Like the IO boards for earlier Compute Module products, this breaks out all the interfaces from the Compute Module to standard connectors, providing a ready-made development platform and a starting point for your own designs.

The IO board provides:

• Two full-size HDMI ports
• Gigabit Ethernet jack
• Two USB 2.0 ports
• MicroSD card socket (only for use with Lite, no-eMMC Compute Module 4 variants)
• PCI Express Gen 2 x1 socket
• HAT footprint with 40-pin GPIO connector and PoE header
• 12V input via barrel jack (supports up to 26V if PCIe unused)
• Camera and display FPC connectors
• Real-time clock with battery backup

CAD for the IO board is available in KiCad format. You may recall that a few years ago we made a donation to support improvements to KiCad’s differential pair routing and track length control features; now you can use this feature-rich, open-source PCB layout package to design your own Compute Module carrier board.

In addition to serving as a development platform and reference design, we expect the IO board to be a finished product in its own right: if you require a Raspberry Pi that supports a wider range of input voltages, has all its major connectors in a single plane, or allows you to attach your own PCI Express devices, then Compute Module 4 with the IO Board does what you need.

We’ve set the price of the bare IO board at just $35, so a complete package including a Compute Module starts from $60.

Compute Module 4 Antenna Kit

We expect that most users of wireless Compute Module variants will be happy with the on-board PCB antenna. However, in some circumstances – for example, where the product is in a metal case, or where it is not possible to provide the necessary ground plane cut-out under the module – an external antenna will be required. The Compute Module 4 Antenna Kit comprises a whip antenna, with a bulkhead screw fixture and U.FL connector to attach to the socket on the module.

When using ether the Antenna Kit or the on-board antenna, you can take advantage of our modular certification to reduce the conformance testing costs for your finished product. And remember, the Raspberry Pi Integrator Programme is there to help you get your Compute Module-based product to market.

Our most powerful Compute Module

This is our best Compute Module yet. It’s also our first product designed by Dominic Plunkett, who joined us almost exactly a year ago.

I sat down with Dominic last week to discuss Compute Module 4 in greater detail, and you can find the video of our conversation here. Dominic will also be sharing more technical detail in the blog tomorrow.

In the meantime, check out the Compute Module 4 page for the datasheet and other details, and start thinking about what you’ll build with Compute Module 4.

The post Raspberry Pi Compute Module 4 on sale now from $25 appeared first on Raspberry Pi.

Noticia Original

Following on from Rob Zwetsloot’s Haunted House Hacks in the latest issue of The MagPi magazine, GitHub’s Martin Woodward has created a spooky pumpkin that warns you about the thing programmers find scariest of all — broken builds. Here’s his guest post describing the project:

“When you are browsing code looking for open source projects, seeing a nice green passing build badge in the ReadMe file lets you know everything is working with the latest version of that project. As a programmer you really don’t want to accidentally commit bad code, which is why we often set up continuous integration builds that constantly check the latest code in our project.”

“I decided to create a 3D-printed pumpkin that would hold a Raspberry Pi Zero with an RGB LED pHat on top to show me the status of my build for Halloween. All the code is available on GitHub alongside the 3D printing models which are also available on Thingiverse.”

Components

• Raspberry Pi Zero (I went for the WH version to save me soldering on the header pins)
• Unicorn pHat form Pimoroni
• Panel mount micro-USB extension
• M2.5 hardware for mounting (screws, male PCB standoffs, and threaded inserts)

“For the 3D prints, I used a glow-in-the-dark PLA filament for the main body and Pi holder, along with a dark green PLA filament for the top plug.”

“I’ve been using M2.5 threaded inserts quite a bit when printing parts to fit a Raspberry Pi, as it allows you to simply design a small hole in your model and then you push the brass thread into the gap with your soldering iron to melt it securely into place ready for screwing in your device.”

“Once the inserts are in, you can screw the Raspberry Pi Zero into place using some brass PCB stand-offs, place the Unicorn pHAT onto the GPIO ports, and then screw that down.”

“Then you screw in the panel-mounted USB extension into the back of the pumpkin, connect it to the Raspberry Pi, and snap the Raspberry Pi holder into place in the bottom of your pumpkin.”

Code along with Martin

“Now you are ready to install the software.  You can get the latest version from my PumpkinPi project on GitHub. “

“Format the micro SD Card and install Raspberry Pi OS Lite. Rather than plugging in a keyboard and monitor, you probably want to do a headless install, configuring SSH and WiFi by dropping an ssh file and a wpa_supplicant.conf file onto the root of the SD card after copying over the Raspbian files.”

“You’ll need to install the Unicorn HAT software, but they have a cool one-line installer that takes care of all the dependencies including Python and Git.”

\curl -sS https://get.pimoroni.com/unicornhat | bash

“In addition, we’ll be using the requests module in Python which you can install with the following command:”

sudo pip install requests

“Next you want to clone the git repo.”

git clone https://github.com/martinwoodward/PumpkinPi.git

“You then need to modify the settings to point at your build badge. First of all copy the sample settings provided in the repo:”

cp ~/PumpkinPi/src/local_settings.sample ~/PumpkinPi/src/local_settings.py

“Then edit the BADGE_LINK variable and point at the URL of your build badge.”

# Build Badge for the build you want to monitor

BADGE_LINK = "https://github.com/martinwoodward/calculator/workflows/CI/badge.svg?branch=main"

# How often to check (in seconds). Remember - be nice to the server. Once every 5 minutes is plenty.

REFRESH_INTERVAL = 300

“Finally you can run the script as root:”

sudo python ~/PumpkinPi/src/pumpkinpi.py &

“Once you are happy everything is running how you want, don’t forget you can run the script at boot time. The easiest way to do this is to use crontab. See this cool video from Estefannie to learn more. But basically you do sudo crontab -e then add the following:”

@reboot /bin/sleep 10 ; /usr/bin/python /home/pi/PumpkinPi/src/pumpkinpi.py &

“Note that we are pausing for 10 seconds before running the Python script. This is to allow the WiFi network to connect before we check on the state of our build.”

“The current version of the pumpkinpi script works with all the SVG files produced by the major hosted build providers, including GitHub Actions, which is free for open source projects. But if you want to improve the code in any way, I’m definitely accepting pull requests on it.”

“Using the same hardware you could monitor lots of different things, such as when someone posts on Twitter, what the weather will be tomorrow, or maybe just code your own unique multi-coloured display that you can leave flickering in your window.”

“If you build this project or create your own pumpkin display, I’d love to see pictures. You can find me on Twitter @martinwoodward and on GitHub.”

The post Pumpkin Pi Build Monitor appeared first on Raspberry Pi.

Noticia Original

The annual UK Bebras Computational Thinking Challenge for schools, brought to you by the Raspberry Pi Foundation and Oxford University, is taking place this November!

The Bebras Challenge is a great way for your students to practise their computational thinking skills while solving exciting, accessible, and puzzling questions. Usually this 40-minute challenge would take place in the classroom. However, this year for the first time, your students can participate from home too!

If your students haven’t entered before, now is a great opportunity for them to get involved: they don’t need any prior knowledge. 

Do you have any students who are up for tackling the Bebras Challenge? Then register your school today!

What you need to know about the Bebras Challenge

• It’s a great whole-school activity open to students aged 6 to 18, in different age group categories.
• It’s completely free!
• The closing date for registering your school is 30 October.
• Let your students complete the challenge between 2 and 13 November 2020.
• The challenge is made of a set of short tasks, and completing it takes 40 minutes.
• The challenge tasks focus on logical thinking and do not require any prior knowledge of computer science.
• There are practice questions to help your students prepare for the challenge.
• This year, students can take part at home (please note they must still be entered through their school).
• All the marking is done for you! The results will be sent to you the week after the challenge ends, along with the answers, so that you can go through them with your students.

“Thank you for another super challenge. It’s one of the highlights of my year as a teacher. Really, really appreciate the high-quality materials, website, challenge, and communication. Thank you again!”

– A UK-based teacher

Support your students to develop their computational thinking skills with Bebras materials

Bebras is an international challenge that started in Lithuania in 2004 and has grown into an international event. The UK became involved in Bebras for the first time in 2013, and the number of participating students has increased from 21,000 in the first year to more than 260,000 last year! Internationally, nearly 3 million learners took part in 2019. 

Bebras is a great way to engage your students of all ages in problem-solving and give them a taste of what computing is all about. In the challenge results, computing principles are highlighted, so Bebras can be educational for you as a teacher too.

The annual Bebras Challenge is only one part of the equation: questions from previous years are available as a resource that you can use to create self-marking quizzes for your classes. You can use these materials throughout the year to help you to deliver the computational thinking part of your curriculum!

The post Join the UK Bebras Challenge 2020 for schools! appeared first on Raspberry Pi.

Noticia Original

DJ from the element14 community shows you how to build a red-lensed security camera in the style of Portal 2 using the Raspberry Pi High Quality Camera.

Portal 2 is a puzzle platform game developed by Valve — a “puzzle game masquerading as a first-person shooter”, according to Forbes.

Kit list

• Raspberry Pi 4
• Raspberry Pi High Quality Camera
• RPI 6MM WIDE ANGLE LENS
• Red LED

No code needed!

DJ was pleased to learn that you don’t need to write any code to make your own security camera, you can just use a package called motionEyeOS. All you have to do is download the motionEyeOS image, pop the flashed SD card into your Raspberry Pi, and you’re pretty much good to go.

You’ll find that the default resolution is 640×480, so it will show up as a tiny window on your monitor of choice, but that can be amended.

Simplicity

While this build is very simple electronically, the 20-part 3D-printed shell is beautiful. A Raspberry Pi is positioned on a purpose-built platform in the middle of the shell, connected to the Raspberry Pi High Quality Camera, which sits at the front of that shell, peeking out.

The 5V power supply is routed through the main shell into the base, which mounts the build to the wall. In order to keep the Raspberry Pi cool, DJ made some vent holes in the lens of the shell. The red LED is routed out of the side and sits on the outside body of the shell.

Magnetising

This build is also screwless: the halves of the shell have what look like screw holes along the edges, but they are actually 3mm neodymium magnets, so assembly and repair is super easy as everything just pops on and off.

You can find all the files you need to recreate this build, or you can ask DJ a question, at element14.com/presents.

The post Raspberry Pi High Quality security camera appeared first on Raspberry Pi.

Noticia Original

Discover how non-player characters make decisions by tinkering with this Unity-based Pac-Man homage. Paul Roberts wrote this for the latest issue of Wireframe magazine.

From the first video game to the present, artificial intelligence has been a vital part of the medium. While most early games had enemies that simply walked left and right, like the Goombas in Super Mario Bros., there were also games like Pac-Man, where each ghost appeared to move intelligently. But from a programming perspective, how do we handle all the different possible states we want our characters to display?

For example, how do we control whether a ghost is chasing Pac-Man, or running away, or even returning to their home? To explore these behaviours, we’ll be tinkering with AI-Man – a Pac-Man-style game developed in Unity. It will show you how the approaches discussed in this article are implemented, and there’s code available for you to modify and add to. You can freely download the AI-Man project here. One solution to managing the different states a character can be in, which has been used for decades, is a finite state machine, or FSM for short. It’s an approach that describes the high-level actions of an agent, and takes its name simply from the fact that there are a finite number of states from which to transition between, with each state only ever doing one thing.

Altered states

To explain what’s meant by high level, let’s take a closer look at the ghosts in Pac-Man. The highlevel state of a ghost is to ‘Chase’ Pac-Man, but the low level is how the ghost actually does this. In Pac-Man, each ghost has its own behaviour in which it hunts the player down, but they’re all in the same high-level state of ‘Chase’. Looking at Figure 1, you can see how the overall behaviour of a ghost can be depicted extremely easily, but there’s a lot of hidden complexity. At what point do we transition between states? What are the conditions on moving between states across the connecting lines? Once we have this information, the diagram can be turned into code with relative ease. You could use simple switch statements to achieve this, or we could achieve the same using an object-oriented approach.

Using switch statements can quickly become cumbersome the more states we add, so I’ve used the object-oriented approach in the accompanying project, and an example code snippet can be seen in Code Listing 1. Each state handles whether it needs to transition into another state, and lets the state machine know. If a transition’s required, the Exit() function is called on the current state, before calling the Enter() function on the new state. This is done to ensure any setup or cleanup is done, after which the Update() function is called on whatever the current state is. The Update()function is where the low-level code for completing the state is processed. For a project as simple as Pac-Man, this only involves setting a different position for the ghost to move to.

Hidden complexity

Extending this approach, it’s reasonable for a state to call multiple states from within. This is called a hierarchical finite state machine, or HFSM for short. An example is an agent in Call of Duty: Strike Team being instructed to seek a stealthy position, so the high-level state is ‘Find Cover’, but within that, the agent needs to exit the dumpster he’s currently hiding in, find a safe location, calculate a safe path to that location, then repeatedly move between points on that path until he reaches the target position.

FSMs can appear somewhat predictable as the agent will always transition into the same state. This can be accommodated for by having multiple options that achieve the same goal. For example, when the ghosts in our Unity project are in the ‘Chase’ state, they can either move to the player, get in front of the player, or move to a position behind the player. There’s also an option to move to a random position. The FSM implemented has each ghost do one of these, whereas the behaviour tree allows all ghosts to switch between the options every ten seconds. A limitation of the FSM approach is that you can only ever be in a single state at a particular time. Imagine a tank battle game where multiple enemies can be engaged. Simply being in the ‘Retreat’ state doesn’t look smart if you’re about to run into the sights of another enemy. The worst-case scenario would be our tank transitions between ‘Attack’ and ‘Retreat’ states on each frame – an issue known as state thrashing – and gets stuck, and seemingly confused about what to do in this situation. What we need is away to be in multiple states at the same time: ideally retreating from tank A, whilst attacking tank B. This is where fuzzy finite state machines, or FFSM for short, come in useful.

This approach allows you to be in a particular state to a certain degree. For example, my tank could be 80% committed to the Retreat state (avoid tank A), and 20% committed to the Attack state (attack tank B). This allows us to both Retreat and Attack at the same time. To achieve this, on each update, your agent needs to check each possible state to determine its degree of commitment, and then call each of the active states’ updates. This differs from a standard FSM, where you can only ever be in a single state. FFSMs can be in none, one, two, or however many states you like at one time. This can prove tricky to balance, but it does offer an alternative to the standard approach.

No memory

Another potential issue with an FSM is that the agent has no memory of what they were previously doing. Granted, this may not be important: in the example given, the ghosts in Pac-Man don’t care about what they were doing, they only care about what they are doing, but in other games, memory can be extremely important. Imagine instructing a character to gather wood in a game like Age of Empires, and then the character gets into a fight. It would be extremely frustrating if the characters just stood around with nothing to do after the fight had concluded, and for the player to have to go back through all these characters and reinstruct them after the fight is over. It would be much better for the characters to return to their previous duties.

“FFSMs can be in one, none,

two, or however many states

you like.”

We can incorporate the idea of memory quite easily by using the stack data structure. The stack will hold AI states, with only the top-most element receiving the update. This in effect means that when a state is completed, it’s removed from the stack and the previous state is then processed. Figure 2 depicts how this was achieved in our Unity project. To differentiate the states from the FSM approach, I’ve called them tasks for the stackbased implementation. Looking at Figure 2, it shows how (from the bottom), the ghost was chasing the player, then the player collected a power pill, which resulted in the AI adding an Evade_Task – this now gets the update call, not the Chase_Task. While evading the player, the ghost was then eaten.

At this point, the ghost needed to return home, so the appropriate task was added. Once home, the ghost needed to exit this area, so again, the relevant task was added. At the point the ghost exited home, the ExitHome_Task was removed, which drops processing back to MoveToHome_Task. This was no longer required, so it was also removed. Back in the Evade_Task, if the power pill was still active, the ghost would return to avoiding the player, but if it had worn off, this task, in turn, got removed, putting the ghost back in its default task of Chase_Task, which will get the update calls until something else in the world changes.

Behaviour trees

In 2002, Halo 2 programmer Damian Isla expanded on the idea of HFSM in a way that made it more scalable and modular for the game’s AI. This became known as the behaviour tree approach. It’s now a staple in AI game development. The behaviour tree is made up of nodes, which can be one of three types – composite, decorator, or leaf nodes. Each has a different function within the tree and affects the flow through the tree. Figure 3 shows how this approach is set up for our Unity project. The states we’ve explored so far are called leaf nodes. Leaf nodes end a particular branch of the tree and don’t have child nodes – these are where the AI behaviours are located. For example, Leaf_ExitHome, Leaf_Evade, and Leaf_ MoveAheadOfPlayer all tell the ghost where to move to. Composite nodes can have multiple child nodes and are used to determine the order in which the children are called. This could be in the order in which they’re described by the tree, or by selection, where the children nodes will compete, with the parent node selecting which child node gets the go-ahead. Selector_Chase allows the ghost to select a single path down the tree by choosing a random option, whereas Sequence_ GoHome has to complete all the child paths to complete its behaviour.

Code Listing 2 shows how simple it is to choose a random behaviour to use – just be sure to store the index for the next update. Code Listing 3 demonstrates how to go through all child nodes, and to return SUCCESS only when all have completed, otherwise the status RUNNING is returned. FAILURE only gets returned when a child node itself returns a FAILURE status.

Complex behaviours

Although not used in our example project, behaviour trees can also have nodes called decorators. A decorator node can only have a single child, and can modify the result returned. For example, a decorator may iterate the child node for a set period, perhaps indefinitely, or even flip the result returned from being a success to a failure. From what first appears to be a collection of simple concepts, complex behaviours can then develop.

Video game AI is all about the illusion of intelligence. As long as the characters are believable in their context, the player should maintain their immersion in the game world and enjoy the experience we’ve made. Hopefully, the approaches introduced here highlight how even simple approaches can be used to develop complex characters. This is just the tip of the iceberg: AI development is a complex subject, but it’s also fun and rewarding to explore.

The latest issue of Wireframe Magazine is out now. available in print from the Raspberry Pi Press onlinestore, your local newsagents, and the Raspberry Pi Store, Cambridge.

You can also download the PDF directly from the Wireframe Magazine website.

The post AI-Man: a handy guide to video game artificial intelligence appeared first on Raspberry Pi.

Noticia Original