Mr. B
Resolved by Dave Schulpius!
Now I would be more than willing to let DJ borrow my huaduino (and 3.7v battery) if he wants to try and get this board supported. I could pay for shipping both ways. Infact, I would do just about anything to get this board supported.
If you have the time and are interested in my ramblings about what I plan on building, see the bottom. Now back to the point.
I cannot get the huaduino board to be accepted/connected to the ARC software. I was able to connect my standard arduino uno (and get a servo to move) so I should be doing the process right, but it has not worked for my huaduino.
I've previously used this board to build a quadruped (called a minikame) and really like it. I think this is the only board that has all the features I want, built in. I read elsewhere on this forum that the huaduino should possibly work with ARC. I read on the forum that it should/may work with ARC as an uno (although, this sounded too good to be true because I knew that even the standard ide would never work if you selected it as an uno rather than a nano)
(incase anyone doesnt know what a huaduino is, I would call it a spin-off of an arduino nano. It has a built in power regulator that allows you to power many more servos than a normal arduino without damaging the board, with no expansion board needed. It also has the option of charging your required 3.7V lithium battery by simply plugging a micro-usb cable into the board, very swag, much drip)
Now I think I know whats wrong:
- huaduino requires you to select arduino nano in the settings of the standard arduino ide (rather than the ARC supported uno)
- huaduino requires you to select "atmega328p (oldbootloader)" in the settings of the standard arduino ide
So allow me to go through the steps I've tried, just to get these things out of the way-
I sucessfully uploaded ARC's arduino uno firmware onto my huaduino through the standard ide. (with the nano option selected in the ide) I sucessfully found the comport and selected it in ARC. (tried other comports aswell, just incase that was the issue) I changed it to the suggested 57600 baud rate (I tried other baudrates aswell, just incase that was the issue) I tried with the DTR and RTS options enabled. I tried with different micro-usb cables. I tried different comports and usb ports (as previously mentioned) I tried different buadrates (as previously mentioned) I searched for options to change the bootloader in ARC, couldn't find anything I tried re-uploading the firmware onto the board through the arduino ide with uno selected in the settings, rather than the boards suggested option of nano (failed to upload)
Again, I would be more than willing to let DJ borrow my huaduino (and 3.7v battery) If I should of filed a support ticket, delete this thread asap and I'll get the message.
Now here are my somewhat (more like completely) irrelevant, unnecessary ramblings: I'm really excited to start using ARC/synthiam. ARC seems to be exactly what I've been looking for all these years. But just like everything else I've done so far with arduino, getting the pc to connect the board has been the hardest part. Usually its the com-port jumping around and selecting the incorrect bootloader in the arduino IDE that gives me trouble, but my comports have been playing nice with me lately.
I've been trying to build a quadruped for the Robogames convention, more specifically the mechwarfare competition, been struggling for about 10 years now. Spent probably $500 so far on hardware. Dynamixel servos, 9g servos, arduino uno's, arduino nano's, and now two huaduinos (my first huaduino got bricked, it shorted out on the uncovered screws inside the minikame, my fault, should of covered them up with double sided tape or changed the design) Even if the mechwarfare competition goes defunct, even if robogames goes defunct, at this point, I'll never give up.
For those that may be interested or unaware, the mechwarfare competition is what I would describe as a 1v1 mock battle inside a scale city. The robots are armed with (relatively weak) airsoft guns. The hits are registered on pressure sensitive panels that you must incorporate into your design/code. The robots must be quadrupedal (or bipedal). They must be controlled via a FPV camera. The "pilots" are not allowed to view the arena except through their FPV camera(s). I believe autonomy and auto tracking is allowed but rarely implemented. Ofcourse, being the inexperienced roboticist that I am, I initially had grand plans that I quickly had to cut out of the equation. I initially planned on using micro hydraulics for the legs, a HPA airsoft engine (high pressure air, also known as a polar star engine) for the weapon (not to make it higher velocity, but to make it have faster trigger response. low velocity is possible with hpa aswell) (polar star engines can either be powered by an external hpa tank via a hose, or what I was planning on doing is buying the kit from polarstar so you can use a 12g c02 cartridge) (the 12g c02 cartridge would normally go into the "buffer tube" of your airsoft replica therefor I would need to design my own housing for the hpa engine and for the c02 cartridge to give it a smaller/lighter form factor)
I wanted to program gaits to climb the miniature buildings, gaits to leap from side-to-side to avoid bb's, a gait for narrow alleyways, a gait where you drag the front two legs across the floor so as to keep the robot as steady as possible for aiming, and once I realized I couldnt use micro hydraulics (anytime soon) I planned on using dynamixel servos.
Then I decided I wanted to use the heat sensors in the dynamixel servos to allow for a custom OSD (on screen display) to visually show how much heat is in the servos.
I wanted the OSD to display the location of where the "turret" is pointed, relative to where the main body is pointed.
I wanted to give myself an option to power down all servos temporarily during the match if they ever got too hot to prevent damage.
Maybe I'm barking up the wrong tree and I should move onto a different board ? Maybe I'm even barking up the wrong tree by trying to use ARC for this application. I've yet to see how to convert ARC's "ROBOT SKILLS" into code that can be uploaded onto your board for use without being tethered to a pc. (apparently that is called imbedded programming) I still have alot to learn about alot of things, and I'll say that robotics and programming in general have been extremely frustrating, but ARC looks like it has the potential to be the ultimate solution. Modular, expandable, easy to use (once you get the board connected), the self learning stuff, its basically exactly what I would make if I were a software developer, its scary to think about all the potential ARC has (ever see the 1999 movie "Virus"?) but I'm here for it. If robots ever do get out of hand, atleast I've already had some practice mucking them up everytime I accidently short something out lolol
Outstanding! This is great. Have fun and keep coming back. Can't wait to see how this turns out.
Question solved by the way, thanks for pushing me to keep trying.
Excellent, the next step(s) have been shown to me. What a great community
Ps since you’re using a quad legged robot that will need a gait. Use the Auto Position Movement Panel. It’s in the Movement Panel category. manual has examples and lots of info
Thanks for the credit.
I've noticed at times that I have to use a different com port in ARC to connect. I don't know why. Probably a windows thing. I think It happens after I have worked on some parts of my ARC project.
When I have this issue I click in the window of the offending connection (can't remember if it is left or right click) in the connection tool of ARC. A list of connection options pop up. I'll see a different com port listed other then the one I've been connecting to. When I click on that other com port that different com port will auto fill in and I can connect. After I connect I change back to the old com port listed and save. Weird but it works. After I've completed my project work I don't have this issue again until I go in to ARC and make changes to the project. Again, I don't know what changes I make that cause this to happen. Sometimes it doesn't happen. It seems completely random. probably a windows thing.
This may be what was happening to you. If you ever have this issue again try to remember to chick this out. It may work for you and save you some headaches.
Since the beginning of PNP/USB, Windows and all operating systems assign a number to a serial port based on the order of when they were detected. Before pnp and USB, serial ports were given a physical port and IRQ in the computer using jumpers on the i/o board. Those days are gone, so now you get what you get. The serial hardware driver cannot say what kind of device is connected to it. If you look at the device manager, you can see the type of USB/UART that is used but not the thing connected. You actually would need to "talk to the thing" for it to tell you what it is. But there is no standard for doing that, so it's impossible.
And that is why all programs that use serial devices cannot show more than a port number.
No problem Dave ! Yes, I've experienced the same thing. I hope it doesn't fail to connect completely on the day I finally make it to robogames. I'll probably make two robots that are exactly the same, that way if something goes wrong on one, I'll still have the other . And I'll be able to salvage parts from one to the other because inevitably, things will start to break when they are needed most. murphys law. two is one, and one is none.
Ah, thats pretty interesting insight DJ. I watched your video on your youtube channel where you're speaking at a conference and you show a slide of all the places you've worked at. You must be quite the polymath.
I had alittle scare today, some magic smoke got released. I was addressing all my servos via the AutoPosition window. I was almost finished adressing them all when all of a sudden the servos started jittering and the board started smoking. I quicky unplugged the battery (which was burning hot), flipped the switch off on the hua, and then unplugged the usb cable from my pc. I think what happened was the exposed terminals on my 3.7v lithium battery touched the heatsink thats ontop of the huaduino. The terminals were exposed because I had to disassemble the battery and remove the voltage regulator (this is required for it to work with the huaduino for some reason) I've since wrapped my battery with tape to prevent that from happening again.
As far as I can tell, everything is still functioning properly. Maybe I bricked another hua like that last one (meaning it won't accept any new code) but thats okay, as long as it still works as an ezb (which it apparently does) Thats One way to stop yourself from salvaging boards from your old projects
Right now I'm struggling at understanding how to properly adjust the steps, speed and delay on the AutoPosition window. After I start messing with their values, then the transistion button doesn't seem to work right, just keeps jumping from one frame to the next rather than being smooth like before I messed with them (even when I set the values to what they were originally) I'm going to start fresh and just start building my forward gait, and I'm not even going to touch the values for speed,steps, or delay. I'll figure it out, I'll get it eventually (after I finish procrastinating (watching synthiam youtube videos and reading the manual DJ linked to me))