Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

All Content in element14 Community
    0 0

    Drones have been around for decades. The first ones were rather primitive, in the World War I and II era. I never thought much about drones until recently. They always seemed like rather harmless devices. But with the advent of what I call "consumer" drones, just about anyone can build, launch, and operate one.

     

    My concern about drones has been an on-air collision with a commercial airliner that I am a passenger in. While I realize I am a mere mortal human being, I'd prefer to postpone my demise as long as biologically possible and not prematurely due to a high flying toy.  There have been a good number of drone mid-air collision accidents (see video below). I think there has been some legislation, but the legislation and policing of violations has to my mind been rather weak to lukewarm.

     

     

    Granted, drones are a great way to have fun, and learn about electronics and aerodynamics. But I'd be more comfortable if there established drone parks, where drones could be flown, played with, tinkered with, hacked, and happily crash into each other.

     

    But my mind was changed this morning while in the safety of my apartment, sipping a Starbucks' Veranda (Blonde Roast) cup of coffee, and reading the NY Times. After plodding through the front page news, I happened to read a story entitled "A Drone Saves Two Swimmers in Australia."

     

    Basically, some swimmers got in trouble on some rough seas and a lifeguard was operating a lifesaving drone and "steered the drone toward the swimmers... then released a yellow “rescue pod” that inflates in the water. The two swimmers grabbed the pod, and with its support they made their way to shore. They were fatigued, but not hurt,"  the story said. "The rescue took just 70 seconds."

     

    Here in Chicago, Lake Michigan is treacherous for swimmers. While the la lokeoks placid, some areas have a strong undertow. People get drowned every year. Perhaps some could be saved if the lifeguards were issued a safety drone.

     

    So, a drone changed my mind.

     

    I won't say I feel a whole lot safer flying. More work needs to be done, especially as the drone technology is evolving and becoming more sophisticated. But they have a place in our society, within limits, of course.


    0 0
  • 11/30/17--09:39: Win Ben Heck's Portable N64!
  • element14's The Ben Heck Show

    Join the Ben Heck team every week for amazing hacks! Watch them build and mod community-inspired projects using electronics!

    Back to The Ben Heck Show homepage

    The Learning Circuit
    sudo Sergeant
    See All Episodes

     

    In the comments below let us know what makes Nintendo special to you!

     

    The biggest fan of Nintendo Wins Ben Heck's Portable N64!

     

     

    Every generation of gaming consoles involve something related to Nintendo.   Even if you stopped playing games after the Atari 2600, you have Nintendo to thank for classics such as Donkey Kong and Mario Brothers.  During the video game crash between 1983 and 1985, many analysts at the time expressed doubts about long-term viability of video game consoles and software.  Revenues for video games peaked at around 3.2 billion in 1983 to $100 million by 1985, a drop of almost 97 percent.  When the North American video game console industry recovered a few years later, it was due to the widespread popularity of the Nintendo Entertainment System (NES).  You could argue that video game consoles as we know them would never have existed had Nintendo failed to single handedly bring the industry back to its feet and save many companies from going bankrupt in the process.

     

     

     

     

    {gallery} My Gallery Title

     

     

     

    {tabbedtable} Tab Label Tab Content
    Gunpei Yokoi: The Engineer

     

    PlayStation, released a console after Nintendo pulled the plug on a collaboration with Sony on a CD version of the Super NES, and their console still uses a shape that's based on the Super Nintendo controller.  The dpad that you see on almost every modern game controller, that comes from Nintendo's Game & Watch Series. The analog sticks and rumble features, found on both PlayStation and Xbox controllers, they were introduced on the N64 controller.  Its not just the hardware, seemingly every console manufacturer has tried to reproduce what makes the Nintendo special to people.

     

    When Super Mario Brothers was a hit, Sega answered with Sonic the Hedgehog. When Microsoft needed to wrestle dominance away from Sony after the release of the Xbox, they took a page out of the Nintendo playbook with Halo.   Even the look and feel of the controller on the Xbox, with its triggers, feels like it was made for a first person shooter like Halo, just like the controller on the N64 felt right for a first-person shooter game like Goldeneye. Nintendo has been the sole link between every generation of game consoles since the NES.

     

    Nintendo has proven to have had more staying power than any console on the market.

     

    Not only that, consoles such as the N64, a portable version of which was the most requested Ben Heck build on the community, the NES and SNES, mini versions of which have flown off the shelves in recent years, prove that Nintendo is perhaps remembered more fondly than any gaming console in history. That's not to take away anything from the Atari 2600 (a favorite of Ben Heck), the Sega Genesis, and the Sega Dreamcast; all of which are remembered fondly by a passionate following event today; but Nintendo has a type of mainstream appeal that those other consoles can't touch.

     

    Is it because Nintendo leads while others follow?  Nintendo beat other consoles to the punch with a slew of beloved first-party game franchises such as Donkey Kong, Mario Brothers, Super Mario Brothers, Metroid, and Pokeman.   Sega answered with Sonic and Xbox with Halo; but would those games even exist without the influence of Nintendo.    Then there is the hardware, Nintendo not afraid to innovate, while features such as the dpad and analog stick find themselves copied on systems as Nintendo looks internally to change things up with every console down to the Switch.

     

     

    Nintendo bets on an Engineer Working a Dead End Job

     

    If you don't get what gaming consoles have to do with an online community for electronics engineers, then you don't have to look any further than Gunpei Yokoi, a maintenance man with a background in electrical engineering to find your answer. Although Gunpei Yokoi majored in electrical engineering from a famous university in Japan, the only company that offered him a job was Nintendo, a company that at the time hadn't developed any electronic toys nor did they have the capability to do so.

     

     

    There his job was to maintain electrical equipment in its playing cards factory, where he was only the second employee who had a college degree. Nintendo can be roughly translated from Japanese to mean "leave luck to heaven", was founded as a playing card company by Fusajiro Yamauchi on September 23, 1889. The reason Gunpei Yokoi was hired for an entry level role in company that hoped to groom him for a role that would be required because of any planned changes with Nintendo's business models.  It was a seemingly dead end job that was given to Gupei Yokoi because of law that took effect in 1965, the year he graduated, forced Nintendo to hire a qualified electrical engineer for their plant.

     

     

    The job he was given didn't require him to use any of his problem solving skills that he had honed in his training as an engineer, he had no regular duties outside of periodically checking equipment. Having plenty of time on his hands, he'd make his own toys using the factory's machine tools, even when he was on duty. Building things was something Gunpei liked to do as hobby since his childhood, but he couldn't see a path forward to do this in his chosen profession.

     

     

    One day, Hiroshi Yamauchi, the third president of Nintendo, caught him making one of these handmade toys, and summoned him to his office later that day. Gunpei expected to be reprimanded for not doing job, but to his surprise he was being ordered by the president of Nintendo to develop a commercial product. No one, not even the president himself thought Nintendo was ushering in a new era that would completely transform how Nintendo into a manufacturer of electronic consumer products.

     

     

    Immediately following this meeting, Yokoi, who had always dreamed of building his own product, spent months on the project, making improvements mechanical design and preparing it for mass production. When the project was completed, it was named the "Ultra Hand" by the president, which hit the market in 1966, was a commercial success, selling over a million units.  The success of the Ultra Hand" was enough to convince Yamauch to establish the company's first ever development division.

    Nintendo Enters Video Game Industry

    Nintendo Enters Video Game Industry

     

    After moving from assembly line to research and development, Gunpei Yokoi teamed up with Masayuki Uemura, Hired away from Sharp where he worked on solar cells, and the two teamed up to develop the Beam Gun, a plastic gun that shot a beamof light with solar cells as targets.  It would be the predecessor of the "zapper" included in the NES console in the mid 80s.

     

    In the mid 70s Nintendo moved into the growing video game market with Yamauchi creating three departments that competed against each other. Their first venture into the video game market involved securing the right to distribute the Magnavox Odyssey video game console in Japan in 1974.  In 1977, they began producing their own hardware in 1977, with the Color TV-Game home video game consoles.  Yokoi tasked a student product developer named Shigeru Miyamoto with designing the casing for several of the Color TV-Game Consoles.

     

    Shigeru Miyamoto was hired as an apprentice in the planning department by Hiroshi Yamauchi in 1977, following an interview arranged by mutual friend of his father's. He helped the company develop the game Radar Scope in 1980.  It achieved moderate success in Japan, but by 1981 it had failed to break into the North American Market. To keep the company afloat, Yamauchi decided to convert unsold Radar Scope units into a new Arcade Unit. Gunpei Yokoi supervised the project, and Shiguru Miyamoto was tasked with doing the conversion because as he put it "no one else was available" to do the work.

     

    Miyomoto originally conceived a Popeye story that revolved around the rivalry between Bluto and Popeye for the affection of Olive Oyl. However, Nintendo couldn't secure the rights to a Popeye adaptation.  He'd eventually settle on a different love triangle, this time between a gorilla, a carpenter, and a girl; calling the game Donkey Kong while citing "Beauty and the Beast" and "King Kong" as influences.  Donkey Kong was the first time that a video game's storyline proceeded the actual development of a video game. The playable character, originally "Jumpman" the Carpenter, but would later be renamed Mario, after Mario Segale, the warehouse landlord.

     

    Donkey Kong was a success and spawned the sequels Donkey Kong Jr. and Donkey Kong 3. Miyomoto's next game Mario Bros, formally renamed Jumpman to Mario, gave him a brother named Luigi, and turned him from a carpenter to a plumber to better suit his appearance. When the NES was released, Miyamoto contributed the second game on the system, Super Mario Brothers, and the third entry in the Zelda Series, Zelda: A Link to the Past on the Super NES, dropping the side scrolling elements found on its predecessors and adding elements that are now commonplace in games today.

    Shigeru Miyamoto and the N64

    The N64 Produced Some of Nintendo's Most Iconic Games

     

     

    When the Nintendo 64 was released, Shigeru Miyamoto was responsible for several games on it, including the first game on the system, Super Mario 64. He guided the design of the Nintendo 64 controller in tandem with the development of Super Mario 64.  Using the lessons he learned from developing Super Mario 64 and Star Fox 64, he produced one of the most iconic games found on the system, The Legend of Zelda: Ocarina of Time. He also produced an N64 Zelda sequel, The Legend of Zelda: Majora's Mask, reusing the game engine and graphics from Ocarina of Time, as well as contributed a variety of Mario spin-offs such as Mario Kart 64 and Mario Party.

     

     

     

    Ben Heck Portable N64

    As for Gumpei Yokoi, in 1979, he conceived the idea of a handheld video game while observing a fellow bullet train commuter passing the time interacting idly with a portable LCD calculator.  This gave birth to the Game & Watch series which he launched for Nintendo in 1980. The modern "cross" D-pad design was developed in 1982 for a Donkey Kong version of Game & Watch. In 1988 Gumpei Yokoi and his team at Nintendo R&DI conceived the Game Boy hand held system. The Game Boy became one of Nintendo's best-selling products, selling over 118 million units worldwide.

     

     

    Ben Heck Portable N64

    However, while most people fondly look back on the NES released in 1983, the Game Boy released in 1989, The Super NES released in 1990, and the N64 in 1997; its a system rarely mentioned by Nintendo and all but forgotten by most that would lead to Gumpei Yokoi's fall from grace with Nintendo. Designed by Gunpei Yokoi, and released by Nintendo in 1995 Nintendo, the Virtual Boy consisted of a head-mounted semi-portable system with one red-colored screen for each of the user's eyes. It's the first portable console capable of displaying true 3D graphics.

     

    Exactly 14 games were released for Virtual Boy in North America, with only a few being met with positive reception.  Critics complained about how the lack of quality of the games and the red-colored graphics combined to create gameplay-induced headaches.  It sold poorly and was discontinued quietly. Yokoi retired from Nintendo following the systems failure and was tragically killed in a car accident the same year the N64 was released.

     

     

    Share your Nintendo story in the comments below. Feel free to talk about anything related to Nintendo and share your memories with the rest of the community. You can talk about a high score, a level or game that was difficult to beat, or games you enjoy playing to this day.  We want to know what makes Nintendo special to you.

     

    Bonus points if your retro gaming experience includes a Nintendo64.

     

    Directions:

    Step 1:  Log in or register on element14, it's easy and free.

    Step 2:Post in the comments section below and tells us what makes Nintendo Special. Videos, pictures and text are all welcomed forms of submission.

    Step 3:  Sit back, relax, and enjoy the show!  We will accept entries until 3:00pm CDT January 28, 2018 and announce our winner January 28, 2018. If you need something to do between now and then make sure to check out what is happening This week on element14 Community, or watch more Ben at element14.com/TBHS.


    0 0

    This challenge gives me an opportunity to implement some ideas I have had to assist my wife in the Kitchen as well as take some new technology equipment and work them into a Cool Design Challenge!

     

    With my family, any involved cooking usually ends up with a laptop being dragged onto a counter to look up information and recipes.  And most likely provide cooking music appropriate to the theme.  December is a big month for Christmas songs to go with the pies and cookies and fudge.  :-)

     

    As the time for applications was extended I find I now have the opportunity to show how my family kitchen looks for something as simple as cookie and gingerbread house creation:

     

    Kitchen ready for cookie decorating!

     

    You can see with the laptop on the counter space becomes a little cluttered.  In fact my wife moved most of the kid ready messy stuff over to the table that you can see in the background.

     

    As you can probably imagine, having delicate computer equipment on the same surface as liquids and various powder mixes seems to be a Murphy Playground!

     

    My project is to take a Raspberry Pi and create a Kitchen CONsole.  Safely above the cooking work areas and easily accessible.  Ready access to recipe management, measurement charts and streaming music!  The only thing cooler would be to add a hands free option...

     

     

    Having a computer in the Kitchen is not a new idea.

     

    Per the Computer History Museum, Neiman Marcus offered a Kitchen Computer in their Christmas Catalog back in 1969.

     

     

    According to the wiki listing for Honeywell 316 this Kitchen Computer was the first time a computer was offered as a Consumer Product!

     

    This petite Pedestal model H316 weighed over 100 pounds and only cost $10,200.00 back then!  (That is about $77,000.00 today!)  For some reason this model never really caught on, other than in the dreams of future kitchen owners.

     

     

    I believe the present is a most opportune time for the Raspberry Pi to step up as a replacement for the aged but loved Honeywell 316!  Low price computer with a hefty amount of power in a small package, what is there not to love?

     

    I have some additional items that I will bring into the build.  A 7" touch screen and a Google AIY voice Kit.

     

    The touch screen of course for providing an interface that does not require a keyboard/mouse setup on the counter once again impacting our workspace.

    Remember when I mentioned the only thing cooler being hands free?  I am excited to see how Google Assistant will interface with the KCON!

     

    I am hoping that the Google Assistant will be a boon for the Kitchen but I will also be running a recipe software package to assist the Chef.

     

    Currently the two that seem most intriguing are Krecipes and Gourmet Recipe Manager.

     

    They both seem very helpful and provide a lot of useful options such as:

    • Recipe Search
    • Shopping List
    • Diet Helper
    • Other options that I have not verified are adding a picture (it will be interesting to see if the RPi Camera will tie into that) and measurement conversions,

    Location is a key part of my project since I want to keep the system up and away from messy problems.Potential spot for flipdown Kitchen CONsole!Ideally I have an 11.5" spacing under my kitchen cabinets that I can custom build a wooden flip down option that will easily hold the Kitchen Console and allow for it to be swung back up and out of the way when not needed.  Thin will be a key for design since the 11.5 inches is from the front of the cabinet to the back wall, by working in wood I should be able to meld the Console with the existing cabinetry and paint to minimize wifey disapproval.I have marked in green an optimal flipdown location in the above picture.All of the commercial options I have found so far seem to focus on an articulating metal arm that really doesn't conceal very well and seems to more be designed to just have the display in a mounted position for the whole world to see 24/7.Aesthetics are important for this project since I want it to be something that my wife will enjoy and not cringe at the sight of.

     

    To summarize and provide a list of goals toward reaching accomplishment I have provided the below:

     

    Goal level 1-  Operational KCON!

    • Install the RPi3 with working OS.
    • Add the 7" touchscreen for interface
    • Add the Google AIY Voicekit
    • install Recipe Software
    • wire up a custom power option
    • install Console in a custom enclosure and test
    • provide blog details showing how this was done to allow others to replicate

    0 0

    WIP

    This blog documents focuses on the power stage of the electronic load that peteroakes, jc2048 and jancumps are designing.

     

    In this post we're laying out a PCB for the power stage - as much as possible with surface mount components. The FET is close to the one peteroakes uses in the original design.

     

    The BOM

     

    Component Header 2 Header 3 Header 4
    P1 8 pin header, 2.54mm
    P2 a binding post, red hirschmann 931714101hirschmann 931714101 -  SOCKET, 4MM, BLACK, PK5 , MLS
    P2 b binding post, black hirschmann 931714100hirschmann 931714100 -  SOCKET, 4MM, BLACK, PK5 , MLS
    P3 a binding post, black tenma 2301tenma 2301 - Binding Post, 36 A, 500 V, Nickel Plated Contacts, Panel Mount, Black
    P3 b binding post, red tenma 2302tenma 2302 - Binding Post, 36 A, 500 V, Nickel Plated Contacts, Panel Mount, Red
    TH1 NTC Thermistor, 10K Vishay NTCS0805E3103JLTVishay NTCS0805E3103JLT -  THERMISTOR, 10K, 5%, SMD, NTC
    Q1 N-Channel Mosfet Infineon IRF3205SPBFInfineon IRF3205SPBF -  MOSFET Transistor, N Channel, 110 A, 55 V, 8 mohm, 10 V, 4 V
    D1, D2 Diode DIODES SBR2A40P1-7DIODES SBR2A40P1-7 -  Standard Recovery Diode, Powerdi®, 40 V, 2 A, Single, 500 mV, 50 A
    R1 100R 1206 any brand
    R2 0R05 Vishay WSHP2818R0500FEBVishay WSHP2818R0500FEB -  SMD Current Sense Resistor, 0.05 ohm, 10 W, 2818 [7146 Metric], ± 1%, WSHP2818 Series
    Cooler Heatsink Startech.com FAN370PRO - Socket 7/370 CPU Cooler Heatsink and Fan

     

     

     

    NTC

     

    For a detailed description on the temperature protection mechanism, check Programmable Electronic Load - Temperature Protection.

     

    The voltage sent to the ADC is very dependent on the NTC. I've selected a Vishay NTCS0805E3103JLTVishay NTCS0805E3103JLT -  THERMISTOR, 10K, 5%, SMD, NTC.

    I'll program the key values. The behaviour is non-linear and it's easier to make a lookup table if the firmware has to be able to deal with different components.

    This will require access to flash to permanently store tha values, and a SCPI function to alter the table if another component is used.

    For the first version I'm going to be selfish and just program for the device that I've ordered.

     

    PCB

     

    Exposed copper

     

    For good thermal relief, and to get the NTC as good termally coupled to the FET as possible,

    I placed a copper pour (here on the front, I'll do the same on the back and stitch them for thermal transport with vias)

    Then i drew a pour on the front mask. The area of pour will expose copper. That means that the NTC has physical contact with the copper that the FET is soldered on.

    In the fine-tuning I will place that NTC closer to the FET so that I can put a tad of heat paste in between. Or I could put a tad of paste between the NTC and exposed copper ...

     

    Attention when placing the binding posts. For the power input, RED is 1 and BLACK is 2.

    For the sense input, BLACK is 1 and RED is 2.

    This is the result of me labeling pin 7 and 8 of the connectors between the driver board and FET board wrong, on both boards .

    The documentation and KiCAD zips are now updated with corrected schematics.

     

    I used these 2 Contextual Electronics videos to refresh how to expose copper layers and place VIA arrays:

     

    Here's the top side of the completed design. I've drawn the FET in green to give perspective.

    In red you see the copper layer, orange is where the solder mask is removed and copper exposed.

    Pink are the drill holes. They are 0.9652 mm, in an array of 9 * 8, spaced 2 mm apart.

     

    On the bottom, the copper pad (green) has the size of my heat sink + some. The removed mask (blue) has the exact size of the sink's bottom profile.

    The pink lines are the mounting slots for the heat sink (see below).

     

    Slots

     

    My heat sink has brackets for mounting. I've cut out slots to allow the brackets to through the PCB and fix them on the top side.

     

     

    I've put some exposed non-connected copper pour around the slots for strength.

    The slot is drawn on the Edge.Cuts layer. I hope that the PCB fab interprets that as slots to be milled out ...

     

    I've attached the KiCAD project, component libs and Gerbers in a single zip. Also the VIA lib that's used here as a separate file (because I share that one across projects).


    0 0
  • 01/21/18--00:06: PiChef - SafeDegree Blog #1
  • Background

    During a recent visit to my in-laws, who own and operate a commercial kitchen, I noticed as part of the morning opening procedure the observation and recording of the cool-room and other fridge and freezer temperatures. My curiosity kicked in and asked why the recording of the temperatures to be told it is a council requirement to log temperatures as it is to do with their food handling licence. Whilst this process took only about 5 minutes of a staff members time, my inner geek started to think of more efficient ways to complete such a trivial task.

     

    So it happens, and as Murphy’s Law always does, the next morning was meet with a scramble of staff and a tirade of phone calls to suppliers - during the previous afternoons close down, the cool-room door had inadvertently been left ajar. Not a huge dilemma, until it became evident the now over worked cool-room compressor had failed during the night and with the door ajar, didn’t leave much coolness by 7am.

     

    So with expense of the cool-room repair, the additional staff hours cleaning and disposing of thousands of dollars of now wasted food products and on top of that a limited menu and loss of income due limited food supplies I decided to come up with a system that would hopefully reduce the chance of such losses and provide an automated process of reporting.

     

    Concept

    After a discussion with the in-laws, they agreed it would be a huge benefit to them and together we came up with a concept that I think will tick all their needs.

     

    The completed design should include a display module that is capable of displaying both the local Fridge / Freezer and remote sensor data. There should be a indication on the display of current alarms. Automated reports should be emailed which include minimum and maximum daily temperatures and any alarms that occurred during the period.

     

    Alarms! Alarms are to include “Over Temp” and “Under Temp” alarms, with the over temp alarm to be notified by a phone call that requires acknowledgement. Under temp and “Data Loss” alarms, which could indicate a power failure or WiFi outage should be reported by a notification SMS. It was decided not to include the addition of a door alarm but to include an “Above Temp” notification which should accomplish the same task by getting staff to check the fridge / freezer state when activated.

     

    As the location has excellent WiFI coverage, that is the preferred method for relaying data between the remote units and master unit - resulting in being a perfect case for both Raspberry Pi 3 and Raspberry Pi Zero W systems.

     

    Key Hardware

    Being that the design contest is primarily based on the Raspberry Pi 3, definitely expect at least one of these to be used. Due to the requirement in the environment I plan to implement, I will be using DS18B20 Thermo Sensors. Being I2C interfaced, I can have more than one sensor to each Raspberry PI. In addition, I plan to also use Raspberry Pi Zero W as remote sensors due to the reduced cost and less hardware requirements.

     

    If I do decide with an onsite backup process, I will need to include a 4G Modem and battery supply (with monitoring). Alternatively, A remote server (such as another Raspberry Pi 3 located externally to provide data backup and data loss notification.

     

    Data will be able to displayed locally on the Raspberry Pi 3, using the 2.4” Screen Hat.

     

    Of course, this is just the theoretically concept so actually hardware may change as the build progresses.

     

    Key Software

    I plan of using Raspbian Stretch as the OS. I have a good understanding of the Linux OS so using Raspbian should not prove to relatively easy to get up and running.

     

    On top of the Raspbian, I will try to using packages available using the Raspbian apt repository to allow it easier for other to follow in my steps. Packages I plan on using will include:

      lighttpd - a light weight but more than capable web server

      php - I am more familiar with php web programming so even though it is probably over kill, it works

      sqlite3 - again a lightweight database often using in embedded devices

      asterisk - a more than capable VoIP server

     

    Though out the design process, I will try my best to include default settings and show script and configuration changes alas, feel free to point something out if I miss anything. Again, the software may change depending on further investigation and what is more suitable.


    0 0

    Background

    Some people love eating while many more people love cooking and/or baking. This cooking hobbyist is not limited to just housewives or professional chefs. There are many different reasons why they love this activity. Besides, there are also many different opinions about a fun part of cooking such as we can eat as we go, do an experiment likes a scientist, enjoy the process even just cleaning activity. Moreover, some of them, posses as an amateur chef.

     

    However, some of these cooking lovers face a difficulty in providing a free time for this related-activities such as checking and preparing the ingredients/food material before cooking or searching/making a new receipt.  These difficulties make the people who want to cook must cancel their plan since some not-significant causes such as the ingredient is not complete and it’s too lazy for buying in that time or they have no idea about cooking menu etc.

     

    Therefore, this project investigates the possibility of building an artificial assistance based on Raspberry Pi dedicated to cooking lovers for supporting some main cooking activities based on Raspberry Pi.  This project will give many benefits for all those who love cooking who face difficulties in time management for their hobby. We called this system as PiCA (Raspberry-Pi Based Chef Assistance)

     

    Project Plan

    Research

    - The problems addressed by the project will be researched.

    - The instrumentation that is needed to quantify the problems will be researched and selected.

    - The challenge kit of parts will be researched with respect to using them in the project.

    System Design

    - Block/Concept diagram.

    - Software Design.

    - Power supply design.

    Material Procurement

    - Material needed for the project will be sourced and procured.

    System Build

    - Electronics build, Mechanical Build, Software programming.

    Developmental Testing

    - System electrical testing, System software testing, System mechanical testing.

    System Application Tests and Evaluation

    - The system will be used to audit my environment.

    Documentation & Conclusions

    - Each of the project plan tasks will include a related blog.

     

    General System Design

    The systems proposed in this challenge is designed for supporting the cooking activities and also for helping the cooking lovers for making a plan and preparing the next receipt including its ingredient. The block of diagram system proposed is shown in Fig.1 below.

     

    Figure 1. System design concept

     

    The systems consist of master and slave based on Raspberry-Pi.

    - Master system. This sub-system also has been equipped with some components such as camera 8MP, touchscreen display, and mini microphone which is connected to Wifi router. Seeing all of those installed component, this master machine has some functions: recording and processing voice; recording and processing the video; interactively displaying the information; sending a message based on WA; and connected to the internet. This part will be installed in the fridge as the main component of the systems.

    - Client machine/slave system. It will be installed by camera 8MP and PiFace Digital. This sub-system has the ability to record and process video also it can connect to other mechanical parts by digital IO. This subsystem will be placed in another area instead of the fridge in order to support the cooking activity mechanically and visually. Between Master and Slave will be connected by BLE based communication.

     

    How it Works?

    The system that we propose aims for helping the user to cook according to the planned menu. Generally, the function of this system can be divided into five including recording, checking, procuring, guiding and mechanically helping (Illustrated in Fig.2)

     

     

    exmaple of application

    Figure 2. Application of proposed system

     

    1. Registering

    Firstly, the user needs to register the ingredient in the registering systems installed in the fridge. This is needed for checking the availability and counting the amount in the respect of planned next menu. This activity can be taken in the master machine.  The counting process is done by image processing based on OpenCV with blobing technique. The speech recognition based on Mel Frequency Cepstral Coefficient (MFCC) will be employed in for easing the communication in the registration process. Besides, the user also needs to register the planned menu including the ingredient needed. He can do this activity by mobile phone or desktop. The comfortable website will be developed. Therefore, he/she can do it in his/her free time before cooking.

    2. Checking

    Two days before the cooking day, the system will check the availability and count the amount of ingredient according to the planned menu. This checking process will run based on the recorded data in the registering process.

    3. Procuring

    After checking the availability and amount of ingredient, if the needed material is absent or is not enough with the receipt of the planned menu, the systems will make a procurement by sending a message (WA) to the seller/market. The confirmation is needed for completing this process. If the seller doesn't reply the request, the system will do second procurement to another seller.

    4. Guiding

    In the day of cooking, the system will produce an alert to remind the user of cooking. The system also provides information whether the ingredient is complete or not. The menu and receipt will be displayed on the touchscreen display.

    5. Mechanically helping

    The mechanical parts connected to the slave machine works in this step. However, this function is disabled and will be developed in the near future after this challenge period.

     

    Closing Remarks

    We have described the proposed design of Raspberry Pi based artificial assistance exploiting many resources. Seeing the feature of Raspberry-Pi, the proposed design will work well according to the objective and it is able to be implemented in the real application. The progress of development this proposed systems will be published in the next post in the near future. Hope our project plan works well.


    0 0

    Wow, I'm so excited to be doing this challenge! But I'm also really nervous. There are a lot of more experienced engineers and this will be the most complicated project I've done on my own. But what better project to do than a fun and not quite impossible challenge? Well, here I go - to the finish line!

     

    Project Overview:

     

    As stated in the synopsis, I'm basically making a cnc cookie machine. Dough goes in, cookies come out. It easily extends to other baked goods as well, like homemade crackers and pie crust, but the first goal is to get some creative cookies perfectly cooked!

     

    The machine consists of 3 main parts. A dough sheeter, the xy plotter and a toaster oven. The dough is flattened to the correct thickness, cut into the perfect shape, and then put into the preheated toaster oven, cooked, and removed - all while I take care of other, non-automated household chores (but more likely just stand there and watch it in fascination).

     

    Concept drawing side view. (A) is the platform, (B) is a rolling pin, (C) is a cutting head, (D) is toaster oven

     

     

    The Raspberry Pi will control the following elements:

    • Display what is being cut
    • Get and interpret gcode from a pre-selected shape
    • Move the platform and cutting head to coordinate as an xy plotter
    • Move the roller up/down/hold position
    • Temperature control on oven
    • Options for delay times, preheating, cooking time, pausing, allowing user to clear excess dough from pan before cooking, etc.

     

    The touch screen will be the user interface to select:

    • the dough height
    • the image to be cut
    • the preheat setting
    • the cooking time
    • starting/pausing/stopping the process, and
    • allowing the user to save settings

     

    The kit is scheduled to arrive Monday for me and I'm really grateful for this opportunity. I hope you all enjoy this journey with me!

    What kind of cookie do you want?


    0 0

    Hello,

     

    I would like to ask for recommendation of a temperature sensor to put into water. I have two household (amateur) applications in mind, one for drinkable and one for non-drinkable water. Temperature range is between ca. -10 and +120 centigrade, precision needed ca. +/- 1 centigrade. Something with a one or two meter cable would be perfect.

     

    I was thinking about some DIY variant, but I am afraid of adding unnecessary thermal capacity to the sensor and shifting the original scale off. Last time I used LM75A LM335, just the non professional solder joints shifted the measured value to ca. -4 centigrade.

     

    Thank you,

    David

     

    EDIT: I meant analog output LM335.


    0 0

    This our the first blog in the Pi Chef Design Challenge. The “our” is because glennvanderveer and I will be collaborating on this project. This year I want to try using collaboration as a way to get new members more involved in participating. We don't know how this will play out, but right now Glenn is keen and I am keen to see if we can make it work. Glenn is a new member, but has lots of technical experience especially in software, so technically it should be a good fit. I think for now we will be doing separate blogs – just linking to each other's blogs until we find some better way to make it look like a cohesive project.

    I wouldn't say I have a great passion for cooking, but I definitely like to eat and this is a great opportunity to see if technology can improve the experience in the kitchen. Our project has several key objectives:

     

    The hardware objectives are:

    • to make a motorized spice dispenser carousel driven by a Raspberry Pi (which is why we call the project the Spice of Pi)
    • to build in a 7” touch screen that can display information that may be useful in a kitchen, such as recipes and Youtube cooking videos
    • to implement microphones and speakers to provide voice recognition, audio feedback and audio accompaniment for the video

    The software objectives are:

    • to implement voice recognition so that the system can be operated hands-free while cooking
    • to implement Google Assistant, providing full hands-free access to the internet and all other Google Assistant services

     

    I will try to be very detailed in what I blog about because my project partner will need to know exactly what he is up against. This may mean exposing a lot of the dead ends I typically go down during a project, but hopefully others will find them entertaining.

    The components we intend to use for the project include a Raspberry Pi 3 of course, but will also have a Google AIY Voice Kit and a 7” touch screen.

    The AIY Voice Kit, which is a combination of Artificial-Intelligence and Do-It-Yourself, makes this more than just an IoT project, it is really a foray into the Internet of Intelligent Systems. Google Assistant is only going to get smarter with time and this is a really great opportunity to start understanding its potential. I can't wait to ask this system a bunch of odd questions.

    When I first started using Raspberry Pi's I never anticipated implementing anything with so much capability on a Raspberry Pi platform. It is very exciting to think we can probably get all this functionality working in a couple of months.

    It promises to be lots of work, but the plan is to develop a system that is very functional, very educational and a lot of fun to use.

    It looks like the spice carousel will hold up to 25 bottles of different spices in 2 rings. The RPi3 will rotate the carousel to bring the selected spice closer and raise the spice bottle selected all by voice command or touch.

    This crude layout was drawn with CAD to see if a 25 spice platter could fit on my 3D printer.

    A few more mm of build space would be very useful....

     

    My next blog will outline some preliminary mechanical design and specify some more components.

    Our proposal was not successful in getting us the project kit (that is my fault), but we spent the effort to set up a collaboration and want to see it through anyway. I think Glenn will do some sort of unboxing of some parts he procured. He might even do an early demo at some point as he is way ahead of me on the software side of the project.

     

    Design Challenge Links:

    Pi Chef Design Challenge

    About the challenge

    The other challengers

    The kit

    Terms & Conditions

     

    Project Links:


    0 0

    Hello!

     

    Busy times here in the household! Wife is very "excited" to finally have a range hood after almost a year without

     

    Edit: Updates on scope of project -

    Goal: a smart, connected range hood to send images of what's cooking and to alert the user if something doesn't seem right.

    First post - Smart Range Hood - Pi Chef Challenge Blog post #1

     

    I am planning on integrating this with my home automation system but that brings a lot of questions as to how exactly it ties in; which components have the intelligence, and how things work during different failure modes.

     

    My automation system started with a simple Arduino Uno about 5 years ago when I stuck a DHT22 sensor outside to see the temperature. It was running on a stand-alone C# application with a SQL database. Now it looks something like this:

     

     

    The server in the middle runs OpenHAB and my own C# application which are the heart of the system. I've recently added Node-Red and Homebridge on a Raspberry Pi. Now with the addition of another appliance with greatly expanded functionality, I need to consider a lot more about how things work during failure modes.

     

    My friend at work complained on Friday about his Google Fiber going down for 16 hours and he couldn't use Alexa, couldn't turn his lights on or off, and couldn't control his TV. He said that his girlfriend was very upset about this... The critical piece here is that they are all running as cloud services. Even the Nest Thermostat works this way to reach your phone. Each individual device may not do a lot of its own processing - it just reads the sensors, then sends data off to the cloud and hopes for the best. To do an action, it must receive a command from the cloud.

     

    In Node-Red flow terms; it would look something like this:

     

    The device reads data in from its sensors, and reports them up to the cloud service.

     

    To carry out an action, it may require cloud connectivity -

     

    And if you have a mobile device, it could further complicate issues since the phone needs to reach out to the cloud in order to get back to the device which is located 15 feet away from you; on the same WIFI network:

     

     

    What would be ideal is that the device can function with a high level of autonomy, and just report back to the server with certain data like on/off status or sensor reporting for use in other systems (don't run the furnace if presence detection shows that no one is home). This means that actions should not be feed back to a server for interpretation before receiving a command to action. A good example is a smart light switch. What is the exact action that happens when the switch is activated? Some would recommend sending the MQTT broker a command that "Button # 76 has been activated" then doing basically nothing. Then any time the module hears a request from the server to activate the relay, it obliges. In other words, the action of hitting the switch does not directly control the relay for activating the light. Granted, that using an abstraction layer can be very beneficial, it can also reduce the ability of some critical device to function autonomously if, say, it can't reach the server. For the end user, this looks like - "I hit the switch and nothing happened" or "my phone still says 'connecting' and i can't get it to work" or "there is a 2 second delay from hitting the switch until the lights come one".

     

    Rather, for something more mission critical, it seems that the device needs some level of autonomy as per the Node-Red flow shown here -

     

     

    The action of hitting the switch flows through the basic logic in the middle, then directly to the relay output. Along with firing the relay, the controller /also/ reports back to MQTT with the current status. No waiting for a server connection; no delays in communication - nothing. Just input --> logic --> output. Additionally, if a server request (MQTT in this example) does arrive, it hits the logic block, then goes out to the relay. So we clearly still have the ability to use external sources and report statuses but aren't a slave to server connectivity. The flow shown above is the general plan that I intend to use for the lights on the range hood.

     

    For the fan control, it is logically very similar, but physically a little different. The fan has multiple windings. The switch on the doner unit requires "LOW" to be activated for "MED" or "HIGH" fan speeds to work. This will be implimented in the logic block in the middle. I still haven't decided on the exact number of physical buttons I will bring out to the end user.

     

     

     

    All of that being said, Here is the proposed method for the system to work:

     

    The range hood will hold the Raspberry Pi, and all sensors to function by itself. When the user presses a button on the front of the unit, it will immediately respond as commanded. In the background, it will tell the server (MQTT Broker) that a status update has occurred. If the user wants to activate the system via the cloud or their mobile device, then the flow is reversed where OpenHab gets the request, publishes to MQTT, then the range hood logic block gets the request and obliges.

     

    There was a good Q&A session with Jon Oxer from SuperHouse recently where he talked about how this all works and what the end user experience ends up being in complex systems where there are many things which can go wrong. He was pushing towards having once central server for everything mission critical, then there is only one component which can fail; versus having distributed intelligence and many things which can fail. I think that for non-mission critical items, and wherever possible, devices should be able to function on their own as well as within a complex ecosystem.

     

    https://www.youtube.com/user/SuperHouseTV/featured

    Physical connections of components:

     

    This may be the most work controls-wise of the operation. I plan to prototype first on breadboard, then if needed use perfboard to create a prototype. If all goes well, I would like to have a custom board actually be created through an online service.

    As far as the suite of sensors and how they physically connect to the Pi, here is what I have to date. I have specifically not researched this before the start of the contest.

     

    Sensor / module Data Communication protocol Input/Output location Receiving method
    DHT 22 Temperature/humidity One-Wire GPIO (pin TBD) Node-Red plugin
    MQ Air Quality Sensors Flamable gas, Methane, Hydrogen Analog Requires ADC over I2C bus TBD
    Grid Eye 2D Heat map digital SPI Bus (1 GPIO required) TBD
    Pi Cam JPG Image digital I2C (proprietary) Node-Red Plugin
    4 channel relay board o/p digital GPIO (4 required) n/a
    Pi Hat touchscreen video output, five button inputs digital SPI (1 GPIO required)

     

     

     

     

     

    Design Phases:

    I am planning this general outline to ensure completion by the due date. The longest lead item will be the sheet metal fabrication, so that must happen up front. I have the general design close to completion and the upcoming post will talk about that. High level design is mostly complete. I think I have enough GPIO and now that I know how each module talks, I can validate that they don't use up the same resources. I think I will be able to get most the information directly into Node-Red meaning less work to do on the back end. Once the sheet metal is ordered (or perhaps as part of that planning) I will start the fun part of mocking up all the components. I plan to make sure that they can all talk. I'll get NOOBS running, install Node-Red and all required plug-ins, the start trying to pull data from the various sensors. After that, I'll have to do some layout of the internal hood to have places to mount all the stuff. This will result in a 3D printed mounting plate or series of mounts. Hopefully at this point I will have all the required circuitry decided and can work on getting one fabricated.  Once all the final stuff is here, I can work on full implimentaiton and begin isntalling everything. I may get into this early if I put the doner hood up into location while waiting on the new sheet metal.