I have a port of the IK hexapod code from KurtE and Xan for Windows 10 IOT and the Raspberry PI 2 B (C#). Written in Visual Studio 2015. In theory it should work for any platform that Windows 10 IOT supports.
It takes advantage of the wireless Xbox 360 controller for remote control. There is quite a significant improvement over the java port for raspbian in regards to speed and responsiveness.
It uses the Raspberry PI 2 on board UART for communication with the SSC-32. It uses a Windows wireless Xbox 360 controller receiver to communicate with the Xbox controller.
If there is any interest I will gladly post the solution.
We are very curious to see your solution! Do you intend to share it on a platform such as GitHub? If so, we might give it a try with one of the Lynxmotion hexapod with an SSC-32U & RPi2 after the holidays and see how well it works!
Are you going to try it on one the hexapods you are working with? It would be cool to see if it will work properly on other hardware and get feedback on the code.
I did notice some oddness when switching gait or when bodyPosY is set to a small/large value. Not sure on the thresholds for that. Right now it was sort of trial and error to find a range that works. Also playing with the nomGaitSpeed as that seems pretty specific to the particular servo used.
I will be doing some remapping as to how the controls work, trying to make it more intuitive. However I am having some issues trying to get values for the X/Y/A/B/start/back buttons, they always show as not pressed. After they work, I was going to use them for gait, gait speed and bodyPosY.
Once time permit, the goal would be try this on either this one or that one. Do you have any recommendations or pitfalls to avoid that we should be careful with when trying this?
Didn’t realize there was a larger hexapod body available! Neat!
Windows 10 IOT on the PI should be configured to run in “Headless” mode. The application is a background application and can be configured to start when the PI boots up.
The max/min values for servo travel need to be set for your application. I will make these configurable at some point.
The configuration file needs to have the correct servo for each leg which is the 3rd number between the “|”. The first two numbers will eventually be the min/max values for that particular servo. The first entry in the config file is leg 0 or when looking down at the top of the robot the lower left leg. Then the rest follow clockwise from that point.
Also, if running in headless mode, with the app set as startup, be sure to link the xbox controller as soon as the led on the wireless receiver comes on. In the future I think I will just wait at that point for a valid controller to be attached.
Completed a bunch of refactoring. Ultimate GPS and remote arduino (used for ultrasound sensor control) both work now. Basics of the MPU-9150 / 6050 are there and work, but are not currently used. Wrapped the serialDevice functionality in a serial port class. Reads/saves way points to a local file.
I tried for a couple days to get the query movement status command to work reliably. The best I could do introduced about a 5-10ms delay between moves. Which caused the servos to get hot much more quickly. I went back to using the stop watch to wait for the group moves to complete. Works well now.
The inverse kinematics class should be thread safe now. At least it is finally at the point where it is not experiencing random deadlocks or odd delays.
Trying to work through how way finding and way point following code will work…