Honey, I developed FFB joystick (DIY)

[walmis]

18 minutes ago, sockeye said:

I got a couple of quotes for the sheet metal in@propeler 's design. $300+ here in the us! The tapped holes add a lot of labor cost because they can't be plasma drilled and then tapped due to metal hardening. So they have to be manually placed, drilled and tapped. Doubling the cost. No good.

What about water jet?

 

I attached ffb case laser cut production files I used for the prototype, I used locally sourced 380 × 500 mm x 8 mm plywood sheets.

 

I'll arrange 3d printable stl's later to a github repo probably.

 

Oh, and belts are 375mm 5M and 475mm 5M

 

ffb-case-8mm_laser_1.pdf ffb-case-8mm_laser_2.pdf

Edited July 8, 2021 by walmis

[propeler]

45 minutes ago, sockeye said:

The tapped holes add a lot of labor cost because they can't be plasma drilled and then tapped due to metal hardening.

I've tapped all holes manually without problems, 20 minutes of work   Ask only for cutting and bending

Edited July 8, 2021 by propeler

[Mabond96]

Amazing work @propeler! Is it possible to use the internal hall effect sensors available from APS? 

 

[propeler]

6 hours ago, Mabond96 said:

Is it possible to use the internal hall effect sensors available from APS? 

No. Hall sensors can be used only if there is some rotaion speed. For purpose of controlling motor torque almoust in static position we need to use another kinds of sensors.

[Mabond96]

27 minutes ago, propeler said:

No. Hall sensors can be used only if there is some rotaion speed. For purpose of controlling motor torque almoust in static position we need to use another kinds of sensors.

Oh of course. Thanks! What type of sensor did you use? 

[TomVR]

On 7/8/2021 at 9:38 AM, sockeye said:

I've printed@propeler 's gimbal and ordered the bearings. I've ordered the 180kv motors that@walmis suggested.

I got a couple of quotes for the sheet metal in@propeler 's design. $300+ here in the us! The tapped holes add a lot of labor cost because they can't be plasma drilled and then tapped due to metal hardening. So they have to be manually placed, drilled and tapped. Doubling the cost. No good.
@walmis are you willing to share your mdf case stls or should I design something similar for myself?

Also@walmis I suspect your board design will work with those new motors just fine? If so I'll order a couple of them for myself so you can have another "tester".

I'm so grateful for all the work you guys have put into this. Can't wait to get another ffb stick up and running!

Sent from my moto g(6) using Tapatalk
 

tapping holes in metal is a DIY maker rite of passage.

Just get some practice pieces and my god use tapping oil

EDIT: for a better time get the wholes watercut undersized and then drill them out by hand so you know they are the right diameter for the tapping.
 

 

Edited July 13, 2021 by TomVR

[SquidgyB]

I'm wondering if anyone here had issues using AS5048A encoders via SPI and the ODrive, and if so (or not, as the case may be), what circuit did you use with respect to filtering noise out?

I've had the TLE5012 encoders working with ABI, but I'd really like the absolute reading rather than depending on mechanical/hall effect switches as endstops - but all my attempts (now using RJ45 connectors, shielded ethernet cables and prototype PCBs have left me with rising SPI errors rates and very occasional shadow count readings being picked up...

Specifically, I'm wondering what resistors and capacitors were used and how they were connected to allow two encoders over SPI, sharing SCK and MISO respectively between the two and running CSn separately to each encoder (as I understand it should be done).

[propeler]

22 hours ago, SquidgyB said:

I'm wondering if anyone here had issues using AS5048A encoders via SPI and the ODrive, and if so (or not, as the case may be), what circuit did you use with respect to filtering noise out?

I've had the TLE5012 encoders working with ABI, but I'd really like the absolute reading rather than depending on mechanical/hall effect switches as endstops - but all my attempts (now using RJ45 connectors, shielded ethernet cables and prototype PCBs have left me with rising SPI errors rates and very occasional shadow count readings being picked up...

Specifically, I'm wondering what resistors and capacitors were used and how they were connected to allow two encoders over SPI, sharing SCK and MISO respectively between the two and running CSn separately to each encoder (as I understand it should be done).

The problem is not in cables and filters. SPI line shares connections with motor drivers and intrerfere with it. Only way I managed SPI for external devices to work on ODrive is to use separate SPI line.  M0_ENC_B,M0_ENC_A and GPIO8 can be switched to SPI1 lines. Everything else that described on ODrive forum did not help.

[SquidgyB]

1 hour ago, propeler said:

The problem is not in cables and filters. SPI line shares connections with motor drivers and intrerfere with it. Only way I managed SPI for external devices to work on ODrive is to use separate SPI line.  M0_ENC_B,M0_ENC_A and GPIO8 can be switched to SPI1 lines. Everything else that described on ODrive forum did not help.

 

Aaaaaaah, that would explain it - as of last night I managed to get SPI sort of working - I added 10k resistors between 3.3v and SCK, MISO and the two CSn's and this seemed to calm things down a bit (getting shadow count that made sense, no SPI errors), BUT... Still having motor calibration errors which seemed to cause SPI errors.

 

This always happened after trying to calibrate, so I'm guessing the motors were interfering with the SPI data and knocking it off kilter until a full power cycle was done.

 

So, the changes you made to run SPI over the alternate pins - I assume that's through modifying the source code and building your own firmware version from that? 

[Alterscape]

I can say from experience building a DIY collective circuit on a breadboard that the AS5048B is very sensitive to power supply noise, in addition to noise on the data lines. Resistance in the connections of the low-quality solderless breadboard I was using reduced the voltage at the AS5048B board to ~3.0v from 3.3v at turn-on, and I guess voltage drop from power-up of the Teensy I was using as an MCU pulled the voltage just a bit lower right when everything is first connected to USB. This manifested in functioning I2C communications, but complete junk data -- the angle value returned was just noise, and the status registers showed auto gain was at max. Removing and re-applying power to just the AS5048 was the only way to recover the IC. Building a real PCB with negligible resistance, and adding some bulk and decoupling capacitors set things right. So it might be worth looking into the stability of the power.  If the ODrive VCC is 5v, the AS5048 datasheet also specifies a 10uF capacitor between 3v3 and GND, which is not present on the eval board. I've been doing 3v3 work so I'm not sure how failing to add that manifests.

Edited July 15, 2021 by Alterscape
Typo!

[SquidgyB]

@propeler Could I ask you for a favour? Would it be possible to get a copy of your pre-made firmware with these SPI changes?

If not, could you help a little with the changes?

I see these lines in spi.c which I think are the ones which need modifying:

 

Quote

 /**SPI3 GPIO Configuration    
    PC10     ------> SPI3_SCK
    PC11     ------> SPI3_MISO
    PC12     ------> SPI3_MOSI 
    */
    GPIO_InitStruct.Pin = GPIO_PIN_10|GPIO_PIN_12;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_PULLDOWN; // Idle clock and MOSI low.
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF6_SPI3;
    HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

    // MISO pull-up required for disconnect detection on SPI encoders with even parity
    GPIO_InitStruct.Pin = GPIO_PIN_11;
    GPIO_InitStruct.Pull = GPIO_PULLUP;
    HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

 

I think I'd also need to remove the lines to initialise the ABI pins as they are set by default, which I think is this section in tim.c:

 

Quote

   /**TIM3 GPIO Configuration    
    PB4     ------> TIM3_CH1
    PB5     ------> TIM3_CH2 
    */
    HAL_GPIO_DeInit(GPIOB, M0_ENC_A_Pin|M0_ENC_B_Pin);

 

...am I on the right track, or am I barking up the wrong tree?

 

Any help is *greatly* appreciated

Edited July 16, 2021 by SquidgyB

[propeler]

On 7/16/2021 at 3:06 PM, SquidgyB said:

Would it be possible to get a copy of your pre-made firmware with these SPI changes?

Unfortunately I do not have one. I use ODrive only as hardware, firmware for it is fully custom made and is to emulate joystick with FFB. It does not have all that original ODrive functionality. What about actual configuration. You can use CubeMX to change controller pin assignments in convenient visual environment and regenerate that configurations from it. Trust me, it is very good tool for it. 

 

And yes, you are on the right way but for me it is too complicated to make all that configurations manually. I prefer to use visual tools for it

Edited July 18, 2021 by propeler

[Alterscape]

propeler, do you have an estimate for when you might release your custom ODrive firmware, or the firmware for the custom board on github? I bought the APS motors and would love to build your gimbal design, but every time I've tried to write microcontroller code for FFB, I've failed, so I'm not motivated to start building until the software is available.  (Alternatively, would you be willing to post just the FFB endpoint part of the code? Based on my prior experience, having a worked example of implementation would make troubleshooting my own code much easier...)

 

[edit]Jumping back into this on my own, I found https://github.com/hoantv/VNWheel which looks like a pretty solid worked example. The good news is, every time I revisit this idea, the community's figured out and published a bit more, and I've got a bit more context between my other projects and my working life (which is hardware, but not gaming hardware!), so everything makes a bit more sense. So, no pressure propeler, publish when you're ready! [/edit]

Edited July 18, 2021 by Alterscape
Did additional homework.

[vogel25]

If you can get your hands on an Arduino Leonardo, you can just drive the motors with the odrive in torque mode and get the controll signals from the motor from the Leonardo with this (https://github.com/jmriego/Fino) on it.

I had it working in the past with simplefoc, so using a odrive should be possible.

For the position i had an extra encoder on the axis that was directly connected to the Leonardo, but I assume you can send the position data of the axis from the odrive to the Leonardo via UART.

1 hour ago, Alterscape said:

propeler, do you have an estimate for when you might release your custom ODrive firmware, or the firmware for the custom board on github? I bought the APS motors and would love to build your gimbal design, but every time I've tried to write microcontroller code for FFB, I've failed, so I'm not motivated to start building until the software is available.  (Alternatively, would you be willing to post just the FFB endpoint part of the code? Based on my prior experience, having a worked example of implementation would make troubleshooting my own code much easier...)

 

[edit]Jumping back into this on my own, I found https://github.com/hoantv/VNWheel which looks like a pretty solid worked example. The good news is, every time I revisit this idea, the community's figured out and published a bit more, and I've got a bit more context between my other projects and my working life (which is hardware, but not gaming hardware!), so everything makes a bit more sense. So, no pressure propeler, publish when you're ready! [/edit]

 

 

[Alterscape]

6 hours ago, vogel25 said:

If you can get your hands on an Arduino Leonardo, you can just drive the motors with the odrive in torque mode and get the controll signals from the motor from the Leonardo with this (https://github.com/jmriego/Fino) on it.

I had it working in the past with simplefoc, so using a odrive should be possible.

For the position i had an extra encoder on the axis that was directly connected to the Leonardo, but I assume you can send the position data of the axis from the odrive to the Leonardo via UART.

Thank you! I do in fact have a pile of Pro Micros with ATMega32U4s, so I will start here. I keep thinking I'm going to develop some fancy STM32 Rust-based firmware, but realistically I can hack this up in an afternoon as you propose, and if I'm unsatisfied with the ATMega32U4 performance, go through the pain of writing descriptors later.

[vogel25]

Quote

16 hours ago, Alterscape said:

Thank you! I do in fact have a pile of Pro Micros with ATMega32U4s, so I will start here. I keep thinking I'm going to develop some fancy STM32 Rust-based firmware, but realistically I can hack this up in an afternoon as you propose, and if I'm unsatisfied with the ATMega32U4 performance, go through the pain of writing descriptors later.

 

There is also an effort atm to get it running on Arduino due Wich is much more powerful, but the developer didn't have a due and couldn't test the changes he made, and i didn't have time to test them yet. Also I didn't have problems with Performance, memory usage was around 75% already, so it's a bit thigh but works. Also you have to change the USB description a bit, because windows has a few problems when it's a generic ffb device, so you have to clone the info of a g940 or msffb2 to get the period effect to work right. All this is documented in the closed issues on the GitHub.

[propeler]

On 7/18/2021 at 7:54 PM, Alterscape said:

propeler, do you have an estimate for when you might release your custom ODrive firmware, or the firmware for the custom board on github?

For custom board firmware and UI to change settings from PC already there. https://github.com/o-devices/bldc-ffb-joystick-base/tree/main/firmware. It is fully functional now. Will make video when return from vacation. ODrive version will be a little bit later, because I work on FFB wheel in parallel as well and it is now in priority.

Edited July 20, 2021 by propeler

[SquidgyB]

On 7/20/2021 at 9:08 AM, propeler said:

For custom board firmware and UI to change settings from PC already there. https://github.com/o-devices/bldc-ffb-joystick-base/tree/main/firmware. It is fully functional now. Will make video when return from vacation. ODrive version will be a little bit later, because I work on FFB wheel in parallel as well and it is now in priority.

 

 

I finally managed to get the encoders working correctly with the ODrive without having to enable a second SPI line - the trick in my setup was to use a tri-state buffer for the MISO lines from the encoder and to move the CSn pins from GPIO_3/4 to GPIO_6/8 (GPIO_4 in particular seemed to give me issues) - I've now successfully calibrated and saved the settings and can turn on the ODrive and go straight to CLOSED_LOOP_CONTROL, without the need for any endstop mechanics at all, which makes me happy

 

Would you be able to share a brief overview (or just a software list) of the way you created your custom firmware? I'm very intrigued by your previous comment that all the configuration is done via visual tools - does this extend to the USB interface (showing up as a FFB HID device, providing axis information and passing the forces to the motor controllers) and motor control from the STM chip as well?

[TomVR]

On 7/8/2021 at 9:55 AM, walmis said:

What about water jet?

 

I attached ffb case laser cut production files I used for the prototype, I used locally sourced 380 × 500 mm x 8 mm plywood sheets.

 

I'll arrange 3d printable stl's later to a github repo probably.

 

Oh, and belts are 375mm 5M and 475mm 5M

 

ffb-case-8mm_laser_1.pdf 13.01 kB · 28 downloads ffb-case-8mm_laser_2.pdf 2.71 kB · 27 downloads

 

Do you have this in a CAD format? I am a madman thinking about trying to 3D print this with an 0.8 nozzle, would make some changes to the design for better assembly of printed panels

[walmis]

16 hours ago, TomVR said:

Do you have this in a CAD format? I am a madman thinking about trying to 3D print this with an 0.8 nozzle, would make some changes to the design for better assembly of printed panels

 

Hi, I've added the box assembly step file

https://github.com/walmis/FFB-Joystick-Base/tree/master/CAD

[98abaile]

So would this solution work with any game that supports FFB? I see mention of firmware but no software; I'm wondering if the control board could be repurposed for an FFB yoke I was planning on building.

[TomVR]

On 7/28/2021 at 5:48 AM, walmis said:

 

Hi, I've added the box assembly step file

https://github.com/walmis/FFB-Joystick-Base/tree/master/CAD

great! I am wondering what makes more sense, to design the holes for the screws for brass inserts, or just have a cutout for T slots for nuts. From what I understand the t slots are great if someone wants to do it in metal, but are actually not very structurally sound in plastic. Thing is the brass inserts then don't really translate to metal, and they are weak in pullout force.

Edit: though I guess if someone is going to do metal, they'd just go back to OG design and get the edges folded anyway. 

I think I am just gonna have tappable holes for the countersunk screws and then inserts for the bearings flanges

Edited August 1, 2021 by TomVR

[TomVR]

On 7/28/2021 at 5:48 AM, walmis said:

 

Hi, I've added the box assembly step file

https://github.com/walmis/FFB-Joystick-Base/tree/master/CAD

first pass on my adjustments

https://github.com/TomHVR/FFB-Joystick-Base/tree/master/CAD

I've got the holes for the countersunk M3 screws as parameters so they can be adjusted either for putting in brass inserts or tapping directly. I also want to design cam and rollers like the object-77b as a counterweight, as the grip I am putting on is from a Tornado GR4 and is very heavy casted aluminum, and having spring centering will both reduce the strain on the motors and let me test the stick before getting the motors running.

I when I have some time again I'm also gonna add a parameter to adjusting the tolerances on the tabs since there is zero in the design as the laser would be adding a bit of space for them to slip together.

Also the plywood causes conflict with the PULLEY_70T_Hollow components, did you create a 3mm spacer for them?

Edited August 1, 2021 by TomVR

[walmis]

On 8/1/2021 at 9:31 PM, TomVR said:

Also the plywood causes conflict with the PULLEY_70T_Hollow components, did you create a 3mm spacer for them?

 

Yes, you will need to print a spacer.

 

I'm using regular wood screws for the sides. I drill a small hole in the side of the plywood and screw in a small wood screw. Tabs do a pretty good job to hold this thing in place. It even holds together without any screws lol. I think wood screws would work also well for plastic.

 

[TomVR]

Using the parameters I can add pilot holes for the wood screws into the PETG, 

Once I've got the design a little more polished up, and get new buildtak for the printer Im gonna put out some test pieces for fitment/tolerances