Monthly Archives: April 2017

App note: Automotive reverse battery protection diode

via Dangerous Prototypes

an_diodes_an1101

Super Barrier Rectifier™ (SBR) from Diodes Incorporated offers good power efficiency compared to normal PN junction diode and design simplicity compared to MOSFETs reverse protection. Link here (PDF)

This application note compares the performance of Diodes Inc. Super Barrier Rectifier™ (SBR) as an automotive reverse battery protection diode with other solutions. An overview of the reverse battery protection requirement and the qualification standards are also presented.

App note: A closer look at LVDS technology

via Dangerous Prototypes

an_diodes_an041-p

A general overview of Low Voltage Differential Signaling (LVDS) from Diodes incorporated. Link here (PDF)

With the increase in demand for high throughputs, current technologies are becoming less efficient. Data transmission devices like RS-422, RS-485, SCSI and other devices are limited in data rate and power dissipation. With LVDS, data rate has increased tremendously to meet the demand in the high bandwidth market and yet still consumes less power than many current devices. LVDS offers low-power. low-noise coupling, low EMI emissions, and switching capability beyond many current standards. LVDS applications can be used anywhere where high data rate is required and needed to be transfer over a distance. LVDS technology can be found in printers, flat panels, switches, routers, audio/video digital signal processing and many more other applications.

How to make a Balboa robot balance, part 5: popping up and driving around

via Pololu Blog

This is the fifth and final post in a series about how to make a Balboa 32U4 robot balance. In earlier posts I covered everything you need to get the robot balancing. In this post I will talk about how to get your Balboa to perform some fun and challenging maneuvers.

[See also: Part 1: selecting mechanical parts, Part 2: inertial sensors, Part 3: encoders, or Part 4: a balancing algorithm.]

If you have been following along, you should now have your robot using its inertial sensors, motors, and encoders together to balance in place. Now it’s time to get it moving! Our first challenge will be to get it to “pop up” from a resting position into a balancing position. Then I will show how you can get the Balboa to drive around while balancing.

Popping up

It’s no fun to have to lift your robot into a balancing position every time you start it up. A decent balancing robot should be capable of starting from a lying down position and using its motors to power itself up to its upright position. This is not a subtle movement requiring precise calibration like the balancing algorithm I discussed in the last post. Instead, you will be applying power close to the motors’ limits, attempting to violently jerk the robot upward. Since we are talking about violent motions, you should do something to protect the components on the PCB, if you haven’t already. I recommend attaching a pair of arms to the mounting holes on the side of the chassis, for example like these LEGO ones:

Balboa 32U4 Balancing Robot with 80×10mm wheels and arms made from LEGO blocks.

As an alternative, if you have an extra tire or a similarly soft item, wrapping it around the top of your robot can provide some protection.

Now let’s try writing some code. Something as simple as driving backward at full speed then putting on the brakes can flip the robot up. Try this, for example:

void setup()
{
  delay(1000);
  motors.setSpeeds(-400,-400);
  delay(1000);
  motors.setSpeeds(0,0);
}

Start the Balboa lying down with the PCB up. You should see the wheels quickly spin up; the robot will head off in one direction then stop suddenly and rotate upward. Depending on your gear ratio and the surface you are testing on, it might quickly flip all the way over or just pop up a few degrees. It will not be very predictable. One problem is that the wheels spin up so quickly that they will probably lose traction with the floor, causing random turning and also not producing as much acceleration as they could. A better strategy is to accelerate gradually:

void setup()
{
  delay(1000);
  for (uint16_t i = 1; i <= 100; i++)
  {
    motors.setSpeeds(-4*i, -4*i);
    delay(10);
  }
  motors.setSpeeds(0,0);
}

The for loop here gradually ramps up the motor speed to the full -400 over one second. You might need to adjust the numbers a little, but this should reduce slipping and get the robot to a more predictable, higher speed, causing a better “pop” when it puts on the brakes. Next, to make it an even stronger pop, try reversing direction instead of just stopping:

void setup()
{
  delay(1000);
  for (uint16_t i = 1; i <= 100; i++)
  {
    motors.setSpeeds(-4*i, -4*i);
    delay(10);
  }

  for (uint16_t i = 1; i <= 100; i++)
  {
    motors.setSpeeds(4*i, 4*i);
    delay(10);
  }

  motors.setSpeeds(0,0);
}

The Balboa should ramp up to full backwards speed in over one second, then change direction, ramping its speed up to full forward over the next second. This additional forward motion applies much more torque to the chassis than simply stopping; in fact, with some configurations of the robot you might even be able to get it to pop up by going directly into a forward drive, without reversing at all. I have found that a balanced combination of forward and backward motion gets my Balboa to pop up quickly without driving too far away from where I started it.

The exact speeds and angles that you get will depend on factors like friction with the surface and battery voltage. To get it to smoothly transition to balancing, you need to get rid of some of that uncertainty. For example, you might want the robot to accelerate backward until it reaches a certain speed, then accelerate forward until it reaches some angle, then launch the balancing algorithm. This means you need to be running the sensor updating code we developed in parts 2 and 3 while doing the pop-up. That’s why I wrote these loops with a 10 ms delay – to match the normal 10 ms update cycle of our main loop and let the sensor updates work just like they do while balancing. After adding a sensor update call, breaking out of the for loops at the desired speed and angle, and playing with all the numbers for a while to optimize it, here’s the pop-up code I ended up using on my Balboa:

  for(uint8_t i=0;i<40;i++)
  {
    motors.setSpeeds(-i*20, -i*20);
    delay(10);
    balanceUpdateSensors();
    if(speedLeft < -40)
    {
      break;
    }
  }

  for(uint8_t i=0;i<20;i++)
  {
    motorSpeed = i*18;
    motors.setSpeeds(motorSpeed, motorSpeed);
    delay(10);
    balanceUpdateSensors();
    if(angle < 35000)
    {
      break;
    }
  }

This code makes the robot accelerate backward until it reaches a speed of -40 as measured by the encoders (about 70 cm/s on my particular Balboa), then reverse direction and accelerate forward until it is 35 degrees from vertical, which turns out to be a good time for the balancing algorithm to take over. As a bonus, when the balancing code starts, it has a good initial value of angle to work with.

Driving around

Now that your robot can pop up and balance in place, you are going to want it to drive around. Say, for example, you want it to drive forward at a speed corresponding to 500 encoder ticks per second. With sensor updates running every 10 ms, that would give you speedLeft and speedRight values of 5. You might think you need to write an additional feedback loop, to constantly check these variables and adjust the motor power up or down proportionally, trying to get them to 5. But your balancing feedback loop is already monitoring the position and using it for feedback, constantly trying to get the position to 0. So all you need to do is subtract 5 from distanceLeft and distanceRight every 10 ms, and the robot will automatically drive forward at the corresponding rate, while balancing. Adding something to the distance variables every cycle will cause the robot to drive backward, and changing the distance variables by different amounts can be used for turns.

The idea is that you are fooling the robot into thinking that it is staying in place as long as it is driving at the desired speed, so that the balancing algorithm does not have to change at all. To complete the illusion, you will need to adjust both the position and speed variables. Here’s the code from our balancer example that accomplishes this:

  distanceLeft -= driveLeft;
  distanceRight -= driveRight;
  speedLeft -= driveLeft;
  speedRight -= driveRight;

The variables driveLeft and driveRight store the desired drive speed for the two motors, and we subtract them from the distance and speed parameters every cycle, after reading the sensors. Of course, this “fooling the robot” technique has some limitations, since the motor’s responses will be different when driving compared to operating near zero speed. For example, driving fast limits the robot’s ability to recover from a forward fall by speeding up even more. But as long as you don’t go too fast, this is a great way to get your robot driving around.

You can use the millis() function along with the modulo operator % to choreograph a little repeating dance. This code makes my Balboa drive in a figure-eight pattern once every 8.192 seconds (divsion by 8192 is a fast operation on a microcontroller, since it is a power of two):

  uint16_t time = millis() % 8192;
  if (time < 1900)
  {
    driveLeft = 20;
    driveRight = 20;
  }
  else if (time < 4096)
  {
    driveLeft = 25;
    driveRight = 15;
  }
  else if (time < 4096 + 1900)
  {
    driveLeft = 20;
    driveRight = 20;
  }
  else
  {
    driveLeft = 15;
    driveRight = 25;
  }

Note that I am just controlling speed here. It’s not actually keeping track of its position and trying to follow a path, so I just had to adjust the timing and speeds until it happened to look like a figure eight. Over time, errors will build up, and it will get off course, and robots with different gear ratios won’t even follow the same path.

What next?

I have said enough on the topic of how to make your Balboa balance, but this is just the beginning of what you can do with your Balboa. Here are some ideas for projects to work on next:

  • Remote control
  • Line and obstacle sensing
  • Raspberry Pi integration
  • Encoder-based dead reckoning for precise path following

Please let us know what you are doing with your Balboa! We would be happy to hear about your progress and answer questions on the Pololu Forum. If you have anything to say about this series or suggestions for future posts, feel free to post a comment below.

Free PCB coupon via Facebook to 2 random commenters

via Dangerous Prototypes

BP

Every Friday we give away some extra PCBs via Facebook. This post was announced on Facebook, and on Monday we’ll send coupon codes to two random commenters. The coupon code usually go to Facebook ‘Other’ Messages Folder . More PCBs via Twitter on Tuesday and the blog every Sunday. Don’t forget there’s free PCBs three times every week:

Some stuff:

  • Yes, we’ll mail it anywhere in the world!
  • We’ll contact you via Facebook with a coupon code for the PCB drawer.
  • Limit one PCB per address per month, please.
  • Like everything else on this site, PCBs are offered without warranty.

We try to stagger free PCB posts so every time zone has a chance to participate, but the best way to see it first is to subscribe to the RSS feed, follow us on Twitter, or like us on Facebook.

A LoRa home environment monitoring gateway

via Arduino Blog

When you’re away from your home, perhaps you’d like to know what is going on there. A camera system is one solution, but is fairly data-intensive and might not be the right method if you’d like to monitor information such as temperature and humidity in several zones. For this, Rod Gatehouse decided to build his own LoRa environment monitoring system using an Arduino Mega.

To keep an eye on things, Gatehouse (aka “RodNewHampshire” on Instructables) came up with an excellent LoRa IoT gateway that can be controlled via four push buttons and an LCD screen. This device can take input from remote stations wirelessly, and can put this data online or push it to a user as a text message.

The system enables a homeowner to monitor the home environment via an Internet accessible dashboard, receive periodic SMS environmental notifications, receive real-time SMS alerts when monitored environmental parameters exceed preset thresholds, and log environmental data to the cloud.

For more details on how Gatehouse set up this project and on his design choices, check out his Instructables page here.

A tale of three Raspberry Jams

via Raspberry Pi

In today’s post, I’m going to share the tales of three Jams: how and why they got started.

Norwich Raspberry Jam

Norwich is a place where I’ve always hoped there would be a Jam. It’s a tech city in the East of England and there’s plenty going on there, but so far no one has been running a Jam. I met Archie Roques at the Jam I run at Pi Towers, and was thrilled to discover that he was planning to set one up with Claire Riseborough.

I wanted to start the Norwich Jam for a few reasons. Firstly because I really love visiting other Jams (CamJam and Pi Towers Jam) and wanted something closer to home. Also because there’s a great tech community in Norwich, so we want to use that to help encourage more young people into tech and digital making. As one of the founders of the Young Makers’ Tech Club, I’ve seen how much tech potential Norfolk’s young people have. It would be great to have a place where we can have more of them getting involved, and somewhere where those who are interested can learn more skills and show them off to others.

I had the idea brewing in my mind for a while. I visited a few Jams and Pi Parties, and started by helping out at the Pi Towers Jam to get a feel of what running a Jam involves. Then Sarah, who works in education at the Forum (a big public building in Norwich, which amongst other things houses the main library and does lots of tech stuff) got in touch, as she’d heard about the idea and wanted to have a Jam as part of their Norwich Gaming Festival. We got a few other people on board and it’s been all go from there!

Finding a venue can be tricky, but sometimes you find the  perfect place, with a vested interest in running a community interest event, especially if it’s for young people. And you never know, they might lend a hand with organising it, too.

The Forum has been really helpful in getting us a venue. They couldn’t host the Jam themselves as they’ve got other events on that week, but they booked us another venue, the fantastic OPEN Norwich.

The Forum has also helped with the organisation – they are overseeing the ticketing, and helping to promote the event (which is good, as they have 33,000 more Twitter followers than I do!). They also are helping with some of the less exciting stuff like insurance and safeguarding, and organising some events for schools and educators to go alongside the Jam, which is great. Claire Riseborough, who has founded a social enterprise with the aim of helping kids to reach their tech potential, has also been instrumental in getting people in the tech community on board and getting the word out. Lots of other people have helped in their fields of expertise, which is great!

I asked Archie how he planned the Jam’s activities, and how he decided what to put on.

We knew that we wanted to have some talks, stalls, vendors and workshops: when we’d been to events like the Pi Party, those were the bits we liked best. We did a quick social media call for volunteers and we’ve had a pretty good response (though there’s always room for one more!).  We’ve got a nice selection of talks and workshops, and we aim to have some more informal general activities for people who don’t want to do anything too formal. The most important thing for us is having as many awesome people there as possible, whether they are visitors or volunteers.

I’d really like to see the Jam continue, probably on a quarterly basis, as there are lots of other more frequent tech events in Norwich. The Norwich Science Festival is coming up in the Autumn, so it’s possible that a science-themed Jam will be on the cards for then!

The first Norwich Jam takes place on 27 May. Tickets are free from Eventbrite. Maybe I’ll see you there?

Raspberry Jam Berlin

James Mitchell is a Scotsman living in Berlin. I first met him when I gave a Raspberry Pi talk in a furniture showroom, and somehow that led him to start a local Jam.

After owning a Raspberry Pi for a few months I started to search for tips, tricks and tutorials online. I then started to notice Raspberry Jams being set up all over the UK. We didn’t have these events in Berlin, so I decided to start a Jam of my own. Thankfully I had loads of support from Jam leaders and even got the chance to meet Ben Nuttall when he visited Berlin shortly before he joined the Foundation. He was a great inspiration!

After getting started with the Jam, lots of things started to fall into place. I started to build a lot more projects, mainly using the Camera Module. I have a little obsession with photography, and I am particularly fond of time-lapse. My kids also started to get involved with the Raspberry Pi. They are still a little young yet but I love that they stay enthusiastic.

James felt that he was missing out on the Raspberry Pi community vibe.

It really was the lack of events in and around Berlin that got the Jam going. I wanted to attend one of the UK Jams, as it seemed full of like-minded people willing to help each other and learn new things – something we sorely lacked here.

I did later manage to attend the Raspberry Pi Birthday Party in Cambridge. While the event was considerably larger than most Jams I had heard about, it was totally amazing to meet the community. It reinforced the sense of belonging I had been looking for.

I held the first Raspberry Jam Berlin in a co-working office that offers their space at weekends for free if you don’t charge for tickets. I had some Pis set up with various add-on boards and we also gave a few talks about the Raspberry Pi.

My favourite thing about the Raspberry Jam is meeting different people and seeing those projects that are getting pushed beyond my own understanding, but also being able to help new people get interested in the Raspberry Pi. It’s very satisfying to know someone has left the Jam inspired!

I asked James what advice he would have for someone setting up a Jam in their area.

Start small, and have a clear outline of what you want from your Jam. Invite a few friends and maybe the local school’s computing teacher. Find your like-minded corner of the community, and with their help expand if you want.

Don’t be intimidated by the size of other Jams. They come in all shapes and sizes and some can be really large. Just keep in mind you are in it to have fun!

You never know how many people will show up to a Jam. Will it be too many, or too few? Here’s James’ take on the dilemma:

It can get a little stressful when you have low numbers, but the key is to ignore the numbers and just enjoy the moment. If one person shows up and they walk away inspired, it’s a job well done.

Wimbledon Raspberry Jam

Cat Lamin went to Picademy in July 2014. She got really excited about the teaching possibilities of the Raspberry Pi, but didn’t know where to start, so she reached out to the community to create local networks for teachers to share their skills. She started a Coding Evening in Twickenham, and helped organise the Wimbledon Raspberry Jam.

Albert Hickey, who organises the Egham Jam, approached me to see if I was interested in helping him run the Jam in Wimbledon. He had been offered a venue and wanted me to be involved from the start. Wimbledon is close to the school I taught in and I knew this would be an excellent opportunity to give some of the children from school the chance to help develop their passions. What I really enjoyed about the Jam was seeing all of the families there. Several parents asked if we could let their children’s schools know about the next one because they were keen to bring more families down!

I was really lucky with Wimbledon Jam, as loads of helpful people were really keen to offer up their time as volunteers. If I’m honest, I took over a little bit, but Albert seemed quite happy to let me handle the actual event while he dealt with the venue. By the end of it, I felt that we had been the perfect team. While Albert negotiated the space, I took on the role of organising the timetable of events. I had to figure out timings for workshops and who was available to run them. We were really lucky that so many people offered their help almost straight away, and it was great having Ben along as a representative from the Raspberry Pi Foundation. It added a sort of official stamp of approval to the day.

I really like having workshops, talks and show-and-tells going on, and we were really lucky that loads of people were interested in doing everything. One of my highlights from the day was watching the Mums creep over to Whack-a-Pi and sneak a go while their children were taking part in workshops – it was very funny!

Cat and Albert have run three Jams at Wimbledon library now. It’s great to see it continue on from the initial event I attended.

Why do people run Jams?

People run Jams for many reasons. I started the Manchester Jam so that I would have a group of people to learn about Raspberry Pi with, and it ended up benefiting hundreds of other people. While organising an event can be a lot of work, it is good fun. It all seems worth it in the end when you see how you can positively affect people you’d never otherwise have met. Here are some more insights from other Jam makers:

Read more in this excerpt from the Guidebook.

If you want to run a Jam, wherever you are, just remember that all these people were once where you are now. If they can do it, you can do it. Find some helpers, share ideas, make arrangements for your first event, and have fun. Be sure to check out the Raspberry Jam Guidebook for tips from other Jam makers, and lots of practical information on organising an event.

There are plenty of Jams coming up in the next month, including Oklahoma, Bogotá, Virginia and Melbourne, as well as lots in the UK, from Egham to Blackpool, Huddersfield to Belfast. Check out the Jam calendar for more.

I’ll be back next month with another Jam round-up, so if you have a Jam story to share, please get in touch! Email ben@raspberrypi.org. I really want to hear about all your experiences.

The post A tale of three Raspberry Jams appeared first on Raspberry Pi.