You may not be able to find what you want ready-built, but it shouldn't be hard to develop your own pedagogy here.
I have a different interpretation of the question than I think the other current answers do. I'm going to put my emphasis on the Active Learning part of the question rather than the Arduino part. I'm going to have to make some assumptions here, since there is incomplete information. First, I'll assume that your students are young people, up through teen years. Next, I'll assume that your purpose is at least two-fold, learning about Arduino and becoming more confident in speaking and explaining things in a peer setting.
For background I'd suggest two things. The first (which I don't suggest doing, but which it is good to be aware of is the game Telephone or Chinese Whispers. I don't suggest passing a technical description from student to student to see how it gets garbled for two reasons, one of which is that it can lead to embarrassment, and the other is that it would take up too much time. But to subvert the issue of garbling in passed messages feedback at each stage is needed to see that the message gets passed faithfully and even improved.
The second thing to look at is two Pedagogical Patterns, Own Words and Peer Feedback. The first suggests that you can get a feel of student understanding by asking them to explain something in their own words, rather than just a repetition of what they have read or heard. The latter pattern suggests that students give feedback to one another.
I might try something like the following in a reasonably sized class of young people. After examining some Arduino project from the literature or of your own devising, I'd suggest a somewhat modified problem with some details the same and some different. I'd divide the class into small groups (say 3 students) and ask them to work for a bit to come up with a solution. I would then ask one of the groups to explain their solution to the others, focusing on the new parts. Sometimes it is appropriate for the group to choose a spokesperson and sometimes it is better to require that each student participate in the discussion.
After the explanation is given, ask the other students to do one or more of the following.
- Ask questions about the solution given
- Comment on the solution, or at least note where more explanation is needed
- Improve on the solution
You can have a couple of teams give their own explanations. If you do this you can also have a vote on which one seems more complete. You can give a prize for the best explanation.
It is also good if you can use a whiteboard or a projector to note the important elements of the solution given and can use this as a framework to fill in as students make comments. You can judge for yourself when the solution is complete enough that it can be implemented and then send them off to build the thing or keep the discussion going until it is more complete. You can make suggestions along the way, of course, to try to bring out missing parts. You can actually give feedback in a subtle fashion by asking the appropriate questions of the speaking team, rather than directly commenting.
This technique works for lots of things, not just Arduino.
With teens, avoiding embarrassment is an important consideration as they are developing their own self image and don't like to see it bruised in public. Younger and older students can be (not always) more open.
Most classes have a few students who try to answer everything and always put their hand up first. Teams are a way to get each student's contribution into the solution, not just those of the loudest speakers.
Making it a bit competitive can be good or bad, depending on the nature of your students.
Try to build such considerations, when they occur, into your pedagogy.