[WIP] 6DOF Odrive/BLDC CNC DIY build

Hello all,

Alexis from France; started building a 6DOF rig based on what I saw from @SilentChill, @Peacemaker105 (not Odrive I know), @PeterW (and others); I know the Odrive/BLDC approach is more challenging but I am quite confortable with code/electronics. Also knowing challenges people already faced on this forum was of great help and allows me to be more prepared.

I am currently a CNC machinist (was an telco engineer in my previous life too) so the rig will be all CNC where applicable. I have already modeled the rig in Topsolid software (similar to Solidworks) which also allowed me to verify potential issues as it has a "mechanism" module where you get to defined a "constrained" configuration with defined joints (pivot for instance).

Aside from the design, I have already ordered most parts (motors/knock-off odrive/encoders/cables/couplers/etc/...); I will be creating a google drive which will include the BOM.

Motors are BLDC 6064 200KV and Odrive are the MarketBase v3.6 48V; I have already bench tested the combo and aside from the initial head scratching, all went well. I started using the custom InsectaTech firwmare but now switched to the latest available original firmware (fw-v0.5.6). That means I am using Turns in FlyPT (v3.7) :



I have made minor mods to the firmware :

- Added soft low and high limits to match what the InsectaTech had; this is more for peace of mind in case of mistakes in FlyPT.
- Since I am planning on using endstops (again for peace of mind) I made a mod in the code to allow for homing to work even when the rig is already at rest with the bottom endstop activated on startup. Without this mod with homing enabled the odrive will fail the homing (I know at least another member of this forum came across this issue (@EricSteijlen). For the endstop I will be using slotted optical switches.

I will be sharing those mods and the firmware for those interested in the google drive.

Travel of the actuator is about 450mm but may vary depending on the SFU1610 I receive (yes forgot to mention, using 1610 ballscrews based on feedback I saw here for noise and such).

Here are a few screenshots of the design from Topsolid :

Complete Actuator (bottom position) :


Complete Actuator (extended position) :


Opto switch (bottom):



Overall design :




Top joint design (inspired from what @Peacemaker105 did) :



For those familiar with CNC milling, my CNC mill at work is using an Heidenhain control, so I have already programmed some parts using an Heidenhain simulator at home so that I only have to upload those at work, and aside from customizing my tools, adjusting to comply to tolerances such as H7, g6, etc for bearing and other things and of course putting correctly the raw part in the vice for the different operations. Below the Universal Joint holder :



Motor Holder :

I am not using Topsolid post-pro to generate the programs by the way, I am actually progamming the old way so that I can make mods easily while at work.

I will try to take videos of the milling when I start (should be in the next 2 weeks); I am still waiting for some parts to make sure the dimensions match what I found online. I am planning to complete 1 actuator first and then move on the next 5 ones when sure everything is fine.

That's it for now, will post YT videos soon later (motor bench test, and topsolid animation).

Cheers guys,

Alexis.

Odrive / BLDC testing :

Design mechanism simulation :

Forgot to mention, I am using Ethernet To Serial conversion for communication with Odrive to avoid EMI; will be using CAT5+ cabling and the serial length will be limited to the length between the USR-TCP232-T2 module and odrive. I saw those from @Dschadu build.

The module looks like this :


I tried using the VCOM software from USR (to create Virtual COM ports on PC) but it was far from great as I could not disable the Nable algorithm and it was sending all packets from FlyPT in buffered burst... I switched to using "Serial to Ethernet Connector" app from "Electronic Team" and it worked great ! I could even configure an ASCII character as the signal to send the packet which is our case is easy as the command is terminated by the return line character (#13) :




With those settings and this app, it worked great, similar to using USB serial / direct COM interface.

Very important note, the serial interface never actually worked for me on the custom InsectaTech firmware, this is what actually triggered me to use the original latest firmware. Basially with the Insecta firmware, I would be able to send command slow and it would work fine, but as soon as I would send lots of info through flyPT (every 2 ms, but I tried higher settings too) the whole odrive would become unresponsive...

Link to my BOM :

https://drive.google.com/file/d/1Jem9iGReol2gM1IAn8WzwaW_47msrIWm/view?usp=sharing

Will keep adding there as I buy stuff; for instance screws, some bearings, etc...

Link to modded Odrive firmware (bin and source) :

https://drive.google.com/drive/folders/1OGa1Az4zo6_d4kKK_wGInfEr_XQdq-jM?usp=sharing

Aside from parameters for homing and endstops which are well documented already, I added extra parameters for the lower/upper soft limits (in turns) :

"axisX.controller.config.trav_upper_lim": 45.0
"axisX.controller.config.trav_lower_lim": 0.0

Changes for the logic are in the communication/ascii_protocol.cpp file :

Line 145 added those lines :

if (pos_setpoint > axis.controller_.config_.trav_upper_lim) {
pos_setpoint = axis.controller_.config_.trav_upper_lim;
}
if (pos_setpoint < axis.controller_.config_.trav_lower_lim) {
pos_setpoint = axis.controller_.config_.trav_lower_lim;
}

odrive-interface.yaml needed changes to support the added config parameters (line 1124)

trav_upper_lim:
type: float32
doc: Max number of turns in ASCII position control
trav_lower_lim:
type: float32
doc: Min number of turns in ASCII position control

And MotorControl/controller.hpp for default values (line 56):

float trav_lower_lim = 0.0f;
float trav_upper_lim = 45.0f;

Regarding the homing changes to allow for lower endstop to be already triggered at startup, MotorControl/axis.cpp is changed.

Line 156 is changed from

if (min_endstop_.config_.enabled && min_endstop_.rose() && !(current_state_ == AXIS_STATE_HOMING)) {

To

if (min_endstop_.config_.enabled && min_endstop_.rose() && !(current_state_ == AXIS_STATE_HOMING) && homing_.is_homed) {