Stacking issues & 9v Battery

[samuk]

@sathya131295 started looking at the case for the ESC. https://github.com/rosmo-robot/Rosmo_3D/issues/2

Is the intention to orientate the board as in the image above?

[sathya131295]

@runger1101001

Current components placement won't be compatible with the stack. Issues I noted,

1. the m-bus header and the other components are placed on the same side.
2. Terminal blocks' position with respect to the m-bus header is not right if we want to route the wires inside.
3. Different sized terminal blocks will interfere with M5-Core standard screw holes.

Also, try using only the 3.5mm terminal blocks, or even better 3.5mm right-angled pluggable terminal block.

I suggest a layout like this to match with the m5 stack.

Reference module

[samuk]

Thanks @sathya131295 could you elaborate on

"2) Terminal blocks' position with respect to the m-bus header is not right if we want to route the wires inside."

In what sense is it 'not right' don't we simply rotate the boards' stack to orientate the cabling correctly against the robot body?

[runger1101001]

The terminal blocks used are the pluggable 3.5p ones, like the ODrive module. They have 7mm height. There is no 3D model for them, so the terminal blocks shown in the 3D model are not the correct ones.

The m5 headers shown in the 3D models are not the correct ones. There are no 3D models for the short male headers, and the female socket header is not quite the right height either.

The orientation seems to be normal for m5 stack - the ODrive module is the same. Because the "top" of the board connects to the m5 core, or the previous module in the stack with not much space to spare, any tall components have to go on the "bottom" of the board, facing downwards...

And thus the module has 2 x m5 headers, one male, as short as I could source it, sticking up from the top of the board, and one female socket, 7mm tall like the terminal blocks, sticking down from the bottom.

So the module is stackable, and should accept other modules top and bottom, or a core module on the top. The fact that the header spacing isn't exactly like other modules which use the proprietary headers can be accounted for by making the module's shell a little taller as needed.

Based on this description, do you still see an issue? Should I order blank boards before assembled boards? Then we could hand-solder in the terminal blocks and some headers and try it out first? It will add 2 weeks at least to the timeline before we get the working prototypes...

[runger1101001]

Regarding your other points,

Is the intention to orientate the board as in the image above?

Yes, that looks right!

Terminal blocks' position with respect to the m-bus header is not right if we want to route the wires inside.

I don't quite understand this. From the first picture in this post, the terminal blocks would be facing the front of the robot, that's perfect, right? Keep in mind the sensor cables come out the side though.

Different sized terminal blocks will interfere with M5-Core standard screw holes.

The 3.5mm pluggable terminal blocks chosen are Amphenol ones, and they will not interfere with the holes. There are similar ones from TE Connectivity which should work too. They're not expensive. Depending on how far they stick backwards, users will probably also be able to choose other terminal blocks. Ones that stick out too far left and right won't work, but hey, we can't support all the world's terminal blocks ;-)

[runger1101001]

Dimensions of terminal blocks used: https://www.mouser.at/datasheet/2/18/20020110-941881.pdf

[samuk]

Based on this description, do you still see an issue? Should I order blank boards before assembled boards? Then we could hand-solder in the terminal blocks and some headers and try it out first? It will add 2 weeks at least to the timeline before we get the working prototypes...

I'd say let's get them populated personally. We could de/re-solder the terminal blocks if they really don't work?

@sathya131295 apologies if I opened the case issue too soon, in retrospect I should probably have waited until we had real boards existing. Would it be better to delay any further work on https://github.com/rosmo-robot/Rosmo_3D/issues/2 until we have them? Would it be helpful if we post you a real board once they arrive?

[sathya131295]

Thanks @sathya131295 could you elaborate on

"2) Terminal blocks' position with respect to the m-bus header is not right if we want to route the wires inside."

In what sense is it 'not right' don't we simply rotate the boards' stack to orientate the cabling correctly against the robot body?

In the current layout, the terminal pins are on the opposite side of the header pins, which will result in an orientation like this. we will need to rotate the core 90deg. If we do that, the power button will collide with the body, and the face of Rosmo will not be symmetric.

Notice in the very first picture, the position of the buttons in the M5 core.

The m-bus headers and terminal blocks must be adjacent to each other is what I feel.

[runger1101001]

I see the problem now... the power button...

Some ideas: maybe it could be turned 180°? The cables would have to reach further, but it's only 5cm, and the power button would then be on the rear. What do you think? Or for the Rosmo, we could use straight terminal blocks instead of the right-angle ones we have in the design. Then the cables would extend downwards from the board into the robot, no matter what side the terminal blocks are put on.

Note: as through-hole parts, the terminal blocks – whatever type we use – are not part of the assembly, so we will have the opportunity to solder whichever ones we want, or indeed even just to solder the wires directly to the board.

Changing the terminal blocks to be on the side is not so easy. Current layout looks like this:

So the sides have the mounting holes, and considerably less space for ports. The terminal blocks would be quite close to the mounting holes, but also the drivers and power-in path with the capacitors are 35mm wide, it will be hard to fit. Not impossible, but hard. And it's not just a matter of rotating the existing layout, since the m5 header would have to stay put, and therefore one set of ports would have to be moved... a lot of work.

And finally, what about Rosmo2, Bosmo and Cosmo (i.e. the next generation of robots)? I have the feeling that the terminal blocks opposite the m5 header, with the sensor ports to either side, is somehow a more "generally useful" configuration.

[samuk]

Thanks, @sathya131295 for raising the issue. I suggest we leave the board as it is & accept the sub-optimal button placement for now. I think there's more work to do in later versions, but my view is we should test things more or less as we have them now.

We should consider adding a physical on-off switch 1 2 somewhere else on the robot body to kill/ enable the 12v to the buck/ESC. I think the M5 would auto-boot when provided 5v from the buck?

[runger1101001]

We should consider adding a physical on-off switch

Normally I would always agree to physical off switches (for safety) but at the envisioned power levels, with the motors we're planning, there really is no need. you can always just pick the robot up, and the motors will stall long before causing injury, or even pain.

but my view is we should test things more or less as we have them now.

I would strongly encourage that. We've come a long way already with designs and "theory" and its time to put it on the road, and try it out. That there will be changes is clear, and acceptable. But otherwise I fear we might put in a lot of "empty miles" optimising things we will decide to do differently anyway once we try it out.

[samuk]

Normally I would always agree to physical off switches

I think we should do it if we can I'll have a look for something suitable. Otherwise, users are likely to leave the ESC powered for an extended duration.

I chose the LifePO4 largely because they're one of the safer lithium chemistries AFAIK.

[sathya131295]

I have given some mounting holes in the Rosmo body. I feel you can use some Hex standoffs and mount the PCB in the body itself, for testing purposes. It will save on 3D printing costs too.

[samuk]

Perfect, thanks @sathya131295

[runger1101001]

Otherwise, users are likely to leave the ESC powered for an extended duration.

That's less of a problem than it seems. Even if they stay on, with FOC control of the little motors the batteries should last many hours. And the ESC can put the drivers to sleep, then power consumption should be fairly low. And the ESC MCU can also go to sleep, it's wake pin is connected to the m5 header, so the ESP32 can wake it up... with that kind of setup the power consumption should be very low indeed, just the status LEDs :-)

But a physical button on the robot might be a good idea anyway, also to give it commands... a cheap way to do a button these days is to use capacitative touch. You can make the buttons as a PCB, with exposed copper surfaces. Normally, the touch can be detected through a few mm of plastic, so the PCB can be internal mounted under the robot's skin. Or the PCB can be visible, its possible to make it look quite nice (i.e. give the buttons shape and lables, etc...)

Of course there are also many mechanical switches to choose from. I like the ones with integrated LEDs, which are input and output at the same time, so to speak.

However, I will make the point that this will somewhat complicate the design and 3D printing, for very little benefit since the M5 core already has switches. I know open-core doesn't, but maybe it makes more sense to add them there, to make it closer to the original core, rather than on the robot?

I chose the LifePO4 largely because they're one of the safer lithium chemistries AFAIK.

They're safer because they can't catch fire, but also more fussy regarding under-charging. So there should definitely be some protection on them if you want them to last...

[samuk]

for very little benefit since the M5 core already has switches.

The risk I see here is fire. I'm not worried about legal liability, but rather moral.

If you're confident that leaving the ESC energised represents very little fire risk then that allays that fear somewhat. We can also say that people should remove the batteries when not in use. In the BOM I've specified what seems to be a reasonably good external USB charger. Getting the batteries in and out will be a bit of a pain, but we can revisit power again in V2.

Probably should add a switch to the Open core..

[runger1101001]

The risk I see here is fire.

LiFePO batteries are fairly fire-proof, but of course at 10A something else could catch fire. On the other hand, if the robot is burning, it's quite small for a safety switch.

As an off/on switch it makes sense, but for it to be compatible with the ESC design with dual 5A drivers it would have to handle 10A... And with all the capacitors on there the initial switch-on currents can be very high. That could be quite some sparks, it should definitely be a high quality switch, the board only has quite basic ESD protection. On the other hand the intended motors are high resistance, so currents can't rise that high anyway (until the motor melts) so you could think about using a smaller, lower powered switch. I don't know.

It's easier in some ways (and definately cheaper) to handle it in the software side, i.e. by reading a simple low voltage button or touch sensor not on the power path, and then disabling the drivers and MCU in software. The drivers are FET switches, so power is cut to the motors, and in the end the result is the VIN isn't powering anything except the pwr indication LED and the part of the drivers that remains active during disabled mode to monitor the enable pin.

But your intuition is quite correct that a switch on the power path would be safer and better. Just more difficult.

We can also say that people should remove the batteries when not in use.

I agree, one should definately do that in a "self built" type robot. Its not a finished device like an iPhone.

Getting the batteries in and out will be a bit of a pain, but we can revisit power again in V2.

I will definitely design a kind of power board, but if Rosmo is to be inexpensive then I would see if we can't find a suitable inexpensive battery charger board on AliExpress. Depending on its features it may solve the on/off switch problem too.

A custom power board with reverse polarity protection, battery charging, power path management, etc will be expensive, maybe not quite as much as the dual ESC but similar.

[samuk]

The Ottodiy solution is quite neat: https://store.ottodiy.com/product/booster/ maybe we should try 9v and see if it's adequate for our needs? If it worked for ~10min or more at a reasonable speed we could specify that. People could of course connect whatever they like, but I wouldn't feel responsible for it..

[runger1101001]

That is super-neat, but the product doesn't say what voltage it is, or am I blind? I'm assuming not 9V though.

How does the 650mAh compare to the 3 LiFePOs?

[samuk]

Yeah 9v: https://www.amazon.co.uk/650mAh-Battery-Rechargeable-Keyboard-Microphone-White/dp/B07HYSMD51

The LifePO4 would give 700mah at 9.6v http://www.soshine.com.cn/a33.aspx

Maybe the 9v square ones could work, with option of https://www.ebay.co.uk/itm/153674516667

[runger1101001]

Hmm, they're 8.4V, so probably 2S LiPos. 9V just isn't a LiIon/LiPo voltage. But close enough. They'd work, methinks.

[samuk]

See also: https://github.com/electronut/ElectronutLabs-snapVCC

With something in the middle to get the 9v out

Or cheap and actually available UBEC (As used by Otto)

[runger1101001]

Nice, a Y-cable for 9V battery tabs must be something that exists...

Really nice, I like that 9V battery emulation very much. A super-nice solution. If we could find one that has under-voltage protection it would be a pretty perfect solution!

[samuk]

Let's just steal Otto's power system? This is the buck they use.

Could even do 2x in series for 16v

[runger1101001]

Nah, I'd combine the Otto buck with the 9V (8.4V) rechargeable you found and that's perfect! We can even make a little hole or door in the case to make it chargeable without removing it. And the power switch to disconnect it when not in use.

[samuk]

Big Clive seems happy with these https://youtu.be/dR_RusM99no?t=239

So I'll update the BOM with a Znter: https://www.aliexpress.com/item/32985529438.htm

BTW if you ever want to update the rosmo.io site/BOM, it's just a case of editing these https://github.com/rosmo-robot/rosmo-robot.github.io/blob/master/index.md You should have write access.

Think this thread has served it's purpose on the stacking and battery questions, so closing now.