Wishes for the next Brainpad

After “playing” a while with my Brainpad to see if it is suiting my courses I found out that I am missing some things.

  • First I would like to have a second Motor-driver best with forward / rewind elctronics to build simple Robots.
  • Second it would be great to have a complete traffic crossing,
  • furthermore I’d like to have more I/O - Pins on 1/10" pin headers. Best would be at least 2 times 8 Pins.
    after removing the touch elements there is enough room on the board for this and I believe this should be not very expensive.

As I mentioned before in another post I’d wish to see the brainpad integrated into the IDE together with the great Simulator!

What do others think about this?

“Second it would be great to have a complete traffic crossing,”

With a green/red/yellow arrows? What makes a complete traffic light other than red/yellow/green?

Or do you mean a set lights going one way, and a set of lights going the other way? Or a 4 way stop?

I would like to have a street crossing. If it’s possible (room/price) with lights for pedestrians.

Everything you need can be extended using click boards. We plan on documenting this better

The advantage of the BrainPad is the fact, that you have several experiments on one board. Otherwise I can use (and I do so in most of my courses) the Gadgeteer kits.
The disadvantage of those kits is that for absolute beginners you need quite a lot of time to put every module a it’s right place.
Furthermore, if you have different classes with different speed of learning a problem is, that you have to mount and dismount the modules every now and then which is not very good for the mechanical contacts.
Classes with higher levels have more complex problems so it is possible to use the holey boards as the time with the same configuration is longer.
Imagine how long the parts will last, if you open the blue box 10x a week, connect the modules you need, do your program, dismount everything and put it in the box.
So the BrainPad is perfect for this situation. But it would be even better if there were more experiments on it. Room for them should be enough.
As the Brainpad is quite cheap it would be possible to by more of them (e.g. one for each pupil) so that connected devices like motors and breadboards can remain connected.
The Click Board header I want to use for a Bluetooth / USB-Serial / Ethernet (if possible) Connection, so this would be blocked.

Completely agree with you and this is why we are trying to keep the brain pad as simple as possible. As traffic lights, two pads can be used to simulate an intersection.

As for expansion, I didn’t mean use few click boards; otherwise, it is gadgeteer like you said. It is more of a single specialized expansion forty the class, if needed.

ETH is using SPI, so you can stack it with the Bluetooth Click. USB-UART is using too much pins on the socket to be stacked with other Click boards.

Maybe it is a language thing. I still cant envision what you mean by a street crossing on the brainpad. Obviously the brainpad is too small for people or cars to drive on it. I’m not trying to be obtuse, and I dont mean to derail the thread, I’m just really curious. Do you mean a tiny intersection drawn on the board, with tiny “do not walk/Go” signs, etc?

So somewhat related, the brainpad and other boards are relatively cheap to make, even in small quantities. It would be possible to design an alternate board custom just for your specific learning requirements (although obviously if it was something GHI did they could get economies of scale an individual would not).

I don’t know how many “free” IO pins the design has, to add more perhaps it would need to move to the G80 chip?

Yes, I suspected it was meant to be four sets of red/orange/green lights, a red-man/green-man pedestrian lights, and perhaps even buttons for pedestrians and car sensor at each point.

Thinking through this a little more, how about designing an add-on board that just connects to the Click header to represent this all?

1 Like

@ mtylerjr
Sorry I’m German
:slight_smile:
A pedestrian crossing would be fine. There should be room enough on the board.
@ brett
With I/O pins I think of digital pins of the CPU just to connect own made devices.

Ohhh.

Since the brainpad uses .Net, I’m not sure it would be precise/deterministic enough for a [em]German[/em] traffic crossing. Maybe an Italian one though- they don’t need to be so precise, since no one pays attention to them anyway :smiley:

:wink:

One more remark regarding the I/O pins I proposed.
How about a Pin-header following the Raspberry pinout. Then we could use the FEZ-Hat for example.

@ mflume - we use the click boards pinout.

About the clickboard pinout…

If I wanted to add a serial device to the brainpad, would it be that difficult to use some i/o pins from that header?

Very specifically, since I want to use the brainpad with scratch, I would really like, in the future, to find a way to route the scratch “Say” statements to a text to speech module.

I have a spare Emic2 TTS module, and am trying to think of a way to do this, but likely it will end up requiring some help from mcalsyn.

But a text to speech interface of some sort would be -ideal- for use with scratch, since the “say” statement features so prominently.

1 Like

I responded on the other thread, but I will add one more point here… Scratch programs run kind of like Arduino programs in that the whole program executes in a continuous non-blocking loop, so a say statement anywhere in the main line code will get repeated endlessly and slow down the program/event loop.

So, either we need to build in some code that makes sure that a given utterance is only spoken once, or the poor user has to include some code that makes sure that a given “Say” is only executed as needed (which kind of defeats the simple nature of Scratch programs).

This is the same problem I have wrestled with for the BrainPad display - either I can treat it like Scratch treats the PC display (as an immediate-mode frame buffer) and then just transfer the changed pixels to the board; or I can send commands to the BrainPad and let it do the rendering, but repeat that rendering every time around the Scratch loop. The former method has the benefit of having no cost when the pixels don’t change, but the latter method is much less complex and overall renders faster and in a more visually appealing way.

I’m surprised about the “Say” command being like that. In my son’s scratch prorgams, the code blocks all have a start (either starting the program manually, or some event,) and an end. To make them loop he needs to specifically insert a loop.

If the event is a one-off trigger, like a keypress, then it only fires once, then ends. Are you saying the converted code for the brainpad wouldn’t work this way? That the whole thing restarts immediately when reaching the end of any block, and has no memory of states of anything? (like the key still being held down and not released yet?)

He has your typical logic issues that can -cause- the ‘say’ to happen repeatedly, but that’s just basic programming learning, and he quickly fixes it to ‘say’ only when he wants to.

I guess I dont understand how the code all gets tweaked to run in such a way that simple logic control statements wouldnt prevent something repeating unnecessarily. I understand it for the display, but not the “say” (unless it is because the “say” needs to linger on the display somehow, when shown graphically… but this wouldnt be a problem with audio)

@ mtylerjr - I do not think scratch should support any expandability as it must be used with the very beginners. Once a beginner learns some programming concepts, they should transition to using a real language.

1 Like

But…that’s what scratch on the brainpad is for, isn’t it? Helping young scratch programmers interface with the world beyond the big computer screen? Leds and sensors and motors/servos and small lcd displays? Text to speech seems like a natural addition… they can do audiofiles already… played on the pc though… I just know macallum (my 9 year old) would like to make robot speech from the scratch language. I’m just thinking of how to make that possible for him…