walmis
-
Posts
300 -
Joined
-
Last visited
-
Days Won
13
Content Type
Profiles
Forums
Events
Posts posted by walmis
-
-
1 hour ago, skypickle said:
Discord Invite does not work.help?
this one should be unlimited
-
Hey, until the website is done you can join the VPforce discord: https://discord.gg/XEXZmQHk3T
There's a #faq channel with the most relevant information.-
2
-
-
5 hours ago, horus-DCS said:
Could you elaborate on the advantage of the Rhino compared to the Brunner?
Hi, I can jump in here
So a couple of advantages of the top of my head:
- Rhino is plug-and-play DirectInput, so no additional software is required for it to run on FFB supported games.
- Rhino has bigger motors and much higher gear reduction - much more torque
- Bigger motors with active cooling don't overheat in normal use cases.
- Price
Here's a video showing versatility of the system in action, showing a mechanical implementation of the Rhino DIY motor kit for a custom cyclic from one of my first clients
-
6
-
Hey guys, I've noticed some FFB related discussions, so I figured I'll jump in a bit since I'm working in the field for quite a while
So I have been developing a a plug and play FFB system for the past few years, and recently started shipping first motor kits and first 'RHINO' FFB bases. The FFB motor kit is aimed for cockpit builders and hobby mechanics who want to build their own stick/cyclic, It solves the complicated problem of system control, motor power delivery, USB communication, etc. I very much hope more people will (re)discover FFB and we, FFB users, will receive more love from ED.
Feel free to join my discord server: https://discord.gg/XEXZmQHk3T to keep in the loop about the latest developments.
My YouTube channel with some FFB demos: https://www.youtube.com/user/walmis
-
4
-
-
10 hours ago, propeler said:
Some updates. From my experience and wishes of real pilots to have more power on the stick so I choose another solution.
Frist - already existing, powerfull and proven by time board as the controller - ODrive coupled with incremental encoder. I wrote custom firmware for it so no need to have a 'tree' of separate boards. You only need to flesh ODrive with custom firmware, and that's all. As the bonus - posibility to use virtually any BLDC motor that does not come out of ODrive power restrictions.
Second - metal as the main material for the gimbal.
As the result variant with motors from hoverboard gives 5kg force(with 10A power source) on the full sized ground mounted flight post. But with more powerfull PSU it definitely capable of handling significantly higher force.
Firmware supports not only standard FFB effects but augmentation with effects based on DCS telemetry - force is affected by speed, G, angle of attack and thrust of motor( and yes, it is possible to use the same augmentation for rudder pedals as well even considering that DCS does not provide effects for rudder axis)
So, for those who wants something more powerfull - you are welcome :)
Good stuff, just don't forget one important piece for such high powered equipment
-
4
-
-
Hey guys, some quick test flights:
I've also made a discord server, so most of the stuff is happening there: https://discord.gg/Y7YmFGHbee
-
2
-
1
-
-
56 minutes ago, propeler said:
Do not hurry! I prety sure that I know what the gimbal inside of it and I can say that it has one serios drawback. That type of gimbal when made from plastic simply can not be done stiff and rigid enouhg to handle high torque. Experiments of other guys here in the topic and my experience showed it. Thats why this
That type of gimbal works perfectly fine for the forces applied in this application. Of course if one wants 20kgf, you might skip the Rhino and build a DYI machine. But as a compact Brunner alternative it works perfectly fine.
Disclaimer: while the gimbal might look similar to yours, I have it redesigned from scratch.
-
4
-
-
7 hours ago, Thadiun Okona said:
Oh my.. those look big enough to use for pedals or a monster warbird stick like VO101_MMaister has been itching to build since forever . How hard can they be driven with the mosfets/psu arrangement on your drive board?
Unrelated but wondering if the 57BLF03 motors you use have a D shaft... I'm toying with the idea of using shaft-winding for power transmission vs belt drive since it can be made really compact even at high ratios. With a round shaft the native 8mm could be used on the drive end but if there's a flat a bigger hub with full round would be needed.The servo drive can be driven up to 30-35A (the limitation is the current-sensing feedback path gets saturated with 1mOhm shunts, MOSFETS are rated up to 175A).
But according to the motor datasheet, peak current is within the servo driver's current limitation. I'll need to test the real world performance. Maybe it's possible to push it more.
The 57BLF03 does indeed have a D shaft:
Can you elaborate more on "shaft-winding"? sounds interesting
-
22 hours ago, II.JG1_Vonrd said:
Do you have plans to sell them?
Yes, definitely!
On 4/11/2022 at 6:13 AM, predator-nz said:just having a good read if you could or maybe implement the 86BLF03 into your PCB that would be great.
Got my hands on a few samples of 86BLF03 motors. Installed the servo drive. Works a treat. Happy to say I will be able to supply them.
Demo of the big boy in action with the 57BLF03 for scale: https://gfycat.com/unrulyentirebilby
-
1
-
-
Hey guys, I've uploaded an album featuring RHINO FFB Base.
-
7
-
-
22 minutes ago, TomVR said:
Consider down the line making a single axis kit, would be interesting to try making rudder pedals that can switch between anti-torque (no centering) or regular rudder pedals, maybe even having airspeed resistance changes for warbirds (you can feel your airspeed in the pedals!)
I have this planned. It will be easy to disable X or Y axis and adjusting the feedback parameters as desired for the single axis!
-
4
-
-
Been researching how to improve the implementation of the Friction effect. Think I found a solution. This will be a solution to implement a Helo Collective for example without messing with complex mechanics.
-
5
-
-
On 4/11/2022 at 2:51 PM, VO101_MMaister said:
Thank you. How much gearing is acceptable without risking a sloppy stick reaction in you opinion? What is the max RPM of the motors?
The motors are rated 3000rpm at 24V. I have used these with my first base, which has 1:24 ratio pulleys. Works just fine
-
1
-
-
37 minutes ago, Thadiun Okona said:
Fantastic, can not wait. Surprisingly clear video covering a lot of general FF concepts along with specifics to your controller, especially impressive seeing as English is not your native tongue. Already downloaded the software and have messed with it a bit but this vid makes the scope of it clear.
Thanks! Although I do lots of reading, listening and writing in English, my English tongue definitely needs some practice
37 minutes ago, Thadiun Okona said:I'm curious about the fans, I only remember seeing 2 wires, is there any way to control their speed?
Yes, they are wired in parallel and the speed is controllable by hardware by modulating the voltage. ATM they are ON-OFF controlled with hysteresis - they start at >=50degC and shut off at <=45degC. If a need arises to change these parameters (perhaps like fan profiles in modern motherboards), I'll happily implement this in the future updates.
37 minutes ago, Thadiun Okona said:Achievable torque with belt reduction (I don't recommend gear boxes, backlash of gears is undesirable) is perfectly fine with 03 motors but curious, is there any reason the 04 version of the motors were not utilized?
Yeah good point about the 57BLF04, the two reasons were: I was not able to find a reliable source and they are too big for my 'Rhino' FFB base. So I invested into the 57BLF03 ones.
There's actually another heavy-duty alternative: the 86BLF03. 2.3kg beasts, 1 Nm continuous and 5 Nm peak torque. Quite tempted to try them, but I'll need to spin another modification of the motor PCBs to accommodate those. -
Hey guys, first video is online:
-
7
-
1
-
-
1 hour ago, VO101_MMaister said:
Hi, what is the rated torque of the system you offer?
The 57BLF03 motors give 0.066Nm/A at the shaft. I drive them at 25A max with active cooling, so that goes to about 1.5Nm. Haven't tested the saturation. But the torque goes quite linearly with current up to max.
One could use a Nema23 gearbox to increase the torque, such as: https://www.aliexpress.com/item/1005002841759258.html [updated]
One benefit of these inrunner motors is the better heat dissipation at standstill, since their coils are on the outside and the whole body acts as a heatsink, in contrast with outrunner motors, which dissipate heat through the front mounting point and the motor bell with the magnets inhibit airflow to the coils. -
13 minutes ago, Roller25 said:
Are you actually taking orders already?
Almost there actually, just figuring out logistics, packaging, shipping prices, etc.
-
4
-
-
First release of device maintenance page for my FFB controller is ready!
The controllers firmware will be upgrade'able over WebUSB. I'll probably move away from desktop app in the future to full configuration over the web.
You can find it here:https://vpforcecontrols.com/usb/rhino/
Supporting stuff is now done, now I finally can start prepping the DYI kits for shipping
-
6
-
1
-
-
Been super busy last few months developing hardware/firmware/software for my FFB system. Pleased to say it's nearing release. I'm also building a small batch of fully plug and play FFB units and drive kits. Gonna do a photo shoot this week so will have more media to share
If anyone's interested in buying a DYI motor/controller kit contact me via PM, I'll need to gauge how many components I'll need to preorder in advance.
Here's a sneak peek of the software side state:
This is the system diagram of connections for the DYI kit.
And the assembled motor unit itself:
-
5
-
-
On 12/28/2021 at 9:54 AM, LimaYankee said:
Naujas invite:
https://discord.gg/f62pdpBrVėl expired
-
11 hours ago, Allan Stark said:
Yes, I compiled psocdude and installed all dependencies and dev libs. /dev/ttyACM0 was present, when I connected Arduino to the USB.
TX/RX Arduino LEDs light up when I run the psocdude, but then go out and I get this error.Do I need to connect the PCB to the USB as well?
Most likely communication is not working with the arduino here. I think you will need to make sure the baudrates are correct here. Check the arduino code Serial.begin(baudrate) and psocdude baudrate flag ( which is -B as I recall)
-
1
-
-
Well, I'll be damned. The FSR utility actually dumped the whole ROM!
There you go guys, flash away!
One thing to note, you need to save calibration data from the old chip from the last 64 byte sector. USB might not work, but HSSP should. That will save the hassle of having to recalibrate the device.
I have a few spare chips, If some of you want a board fixed, let me know via PM. I'm in Europe/Lithuania.out of chips -
16 hours ago, acidwise said:
However, at this point I am skeptical about the romx approach, looking back at the Aigo hack
It might work if code will be executed from flash.[1] We just need to find the entry point, assemble a simple dumper program and patch the existing code and flash it using psoc dude. My guess it would be easiest to just bit-bang using any output pin and capture it using a logic analyzer.
16 hours ago, acidwise said:4. The 64-byte blocks in 2000h-34BEh are identical, which is again strange at the first glance. Hopefully the disassembler will provide a better insight...
Yeah, there was a bug which should be fixed in my arduino_hssp fork.
16 hours ago, acidwise said:I guess you have much more experience in that topic
Ha. Not really, just read the same stuff out there
I have attached the last *correct* dump. I used this one to reflash the chip using psocdude. And since it didn't brick, I assume it's correct
Regarding the bootloader, let's not assume TM is using this bootloader implementation from the app note. Maybe they spinned their own BL which sits in front of flash.
What's interesting is the vector table starting at 000014c0 which should provide some insight. There appear to be some maybe valid jump addresses.
naken_util -m8c -disasm -address 0x0 warthog_throttle_dump.bin0x14e0: 7d 1b e6 ljmp 0x1be6 7 0x14e3: 7e reti 10 0x14e4: 7e reti 10 0x14e5: 30 halt 9 0x14e6: 30 halt 9 0x14e7: 30 halt 9 0x14e8: 7d 1b e9 ljmp 0x1be9 7 0x14eb: 7e reti 10 0x14ec: 7e reti 10 0x14ed: 30 halt 9 0x14ee: 30 halt 9 0x14ef: 30 halt 9 0x14f0: 30 halt 9 0x14f1: 30 halt 9 0x14f2: 30 halt 9 0x14f3: 30 halt 9 0x14f4: 30 halt 9 0x14f5: 30 halt 9 0x14f6: 30 halt 9 0x14f7: 30 halt 9 0x14f8: 30 halt 9 0x14f9: 30 halt 9 0x14fa: 30 halt 9 0x14fb: 30 halt 9 0x14fc: 30 halt 9 0x14fd: 30 halt 9 0x14fe: 30 halt 9 0x14ff: 30 halt 9 0x1500: 7d 1a c2 ljmp 0x1ac2 7 0x1503: 7e reti 10 0x1504: 7e reti 10 0x1505: 30 halt 9 0x1506: 30 halt 9 0x1507: 30 halt 9 0x1508: 7d 03 c7 ljmp 0x03c7 7 0x150b: 7e reti 10 0x150c: 7d 1a 82 ljmp 0x1a82 7 0x150f: 7e reti 10 0x1510: 7d 1a 92 ljmp 0x1a92 7 0x1513: 7e reti 10 0x1514: 7d 1a a2 ljmp 0x1aa2 7 0x1517: 7e reti 10 0x1518: 7d 1a b2 ljmp 0x1ab2 7 0x151b: 7e reti 10 0x151c: 7d 1a f1 ljmp 0x1af1 7I attached full assembly dump for convenience.
EDIT:
Did a diff with HA10T_PSOC_USB_v23
Only change is here, I'd assume it's the calibration data stored in last 64 byte page .
Hmm, wonder If we could squeeze a little dumper program there and jump to it using HSSP.
[1] Infineon-AN2015_PSoC_1_Getting_Started_with_Flash_&_E2PROM-ApplicationNotes-v10_00-EN.pdf section 3.3. "A running program is never prevented from performing internal reads. The romx and index assembly instructions enable the M8C processor to read from flash for any protection level. "So there IS a chance to read the bootloader!
warthog_throttle_dump.hex.txt warthog_throttle_dump.asm.txt warthog_throttle_dump.bin
-
On 1/2/2022 at 1:14 PM, acidwise said:
upd4: Working on a vector attack. Current problem: arduino_hssp from trou does not work, but seems to be necessary. There is quite a number of differences to the version by miracoli, trying to locate the issue. @walmis, how far have you got with the vector attack using the blue pill
There's also my fork https://github.com/walmis/arduino_hssp/commits/master based on miracoli. I've made a few changes you can see in the commit list.
I didn't proceed with the the vector attack. Since resoldering the chip magically worked, I decided not to waste more time on this. But this is interesting nonetheless and hope something comes out of it.
On 1/2/2022 at 1:14 PM, acidwise said:upd2: Managed to dump the firmware (see attachment). There are some difference with the file from walmis. For example, everything up to 0h14BF is completely empty. Need to think about it.
I think first ~6K of flash is the read protected bootloader.
On 1/2/2022 at 1:14 PM, acidwise said:Can someone with a working board dump and share the firmware by using the Thrustmaster utility FlashSpaceReader? This may be a faster way. A copy is attached, original at ftp://ftp.thrustmaster.com/accessories/pc/hotas/exe/HOTAS_Warthog/TMHW_FSR.zip TMHW_FSR.zip
Doubt it will dump the bootloader, but worth a try.
One attack I could think of would be to load an app using existing app structure (see .tmf). I did not manage to find the correct entry point jump address, btw. The rogue app would dump the data of the bootloader using ROMX instruction. It shouldn't be too difficult (I guess) to patch in a loop which would bitbang data to gpio. Sadly the PSoC1 tools are quite old. Maybe some cmdline utilities might be useful from the PSoC1 designer software. I did install that on WinXP virtual machine, LOL.
BTW, I did manage to reflash the same dump using arduino_hssp and psocdude (but without erasing chip ! ) and that firmware worked after resoldering the chip. So that confirms the arduino_hssp should work (my fork).
Info dump:
Infineon-Assembler.book-UserManual-v01_00-EN.pdf
https://github.com/steve-m/m8cutils
https://www.mikekohn.net/micro/naken_asm.php - powerful disassembler/assembler/simulator
Support FFB on Rudder axis
in DCS Core Wish List
Posted
Worse yet is that DCS does not take account which device and which axis is bound in the controls. If there are multiple FFB devices, DCS will send X,Y axis effects and trim position to multiple FFB devices. So if you have FFB stick and pedals connected at the same time, both pedals and stick will receive the stick (x,y) trim position. Luckily we made workarounds when using TelemFFB.
Additionally DCS could add more data to export.lua interface, such as actual trim position, the rest we can implement in TelemFFB app.