Skip to first unread message
Steve Pendergrast
Jul 19, 2018, 5:51:24 PM7/19/18
to Vorpal Robotics Forum
Hello everyone,
Our major new software release, V2r0 is now live! All kit orders starting today will include this new software on both gamepad and hexapod nanos!
NOTE1: It is not required for you to flash this new version of code onto your robot/gamepad. If the robot is working well for you, that's cool. But if you are using Scratch (or think you might) then you would be strongly advised to upgrade to this new version. If you don't then several new Scratch blocks will not function for you (the older blocks will still work).
NOTE 2: If you want to use this new version you must flash BOTH the robot and gamepad. If you only flash one and not the other, there will be a lot of issues and most of the new functions won't work.
HOW TO GET THE NEW FIRMWARE VERSION
Here is a wiki entry on how to flash new firmware onto your gamepad and robot if you are not familiar with using the Arduino IDE:
The Vorpal files archive now shows the new software as the current version. The old software is still there in an ARCHIVE folder.
For your convenience the software, libraries, and supporting drivers are in our dropbox file archive:
Please use the folder "CURRENT-RELEASE-V2" for the new code.
The top level of the github project now also reflects the same code.
NEW SCRATCH EXTENSION
Our scratch extension is now upgraded to the new version of our scratch blocks, which include several new features and greatly expanded capabilities (all of which require the new V2 firmware on robot and gamepad).
The scratch extension is here (this has not changed, and we recommend Chrome browser):
Remember that before running scratch with our extensions, you may need to load the scratch extension plugin and helper if you have not previously done so. The procedure for doing this is documented here:
Documentation for the new features is rolling into the wiki over the weekend, so please bear with us while we sync up everything. I am trying to put together a brief scratch intro video by next week to show some sample uses.
OVERVIEW OF NEW V2 FEATURES
Very brief overview of main new features in V2:
1) TRIM MODE. Holding down W1 while booting the gamepad puts it into trim mode, allowing you to fine adjust the servo positions. A prior post gave a summary of commands. The gamepad guide will be getting a new section on this by tomorrow.
2) DIAL IMPROVEMENTS: The dial on the robot now chirps as you cross into a new mode, and the mode does not take effect until you stop moving the dial for more than 1 second.
3) SCAMPER SUPPRESSION: Scamper was always intended for fairly short bursts (10 to 30 seconds) but many kids will just stay in scamper mode constantly. If a user scampers (W4 walk mode) for more than about a minute, the robot will start to brown out due to the high power draw. First, we slightly decreased scamper speed (not very noticable, 10%) and this does reduce this problem, but if you go long enough it will still happen. Secondly, we suppress scamper mode for 12 seconds if we see a brown out. Scamper mode becomes a normal walk during this period, allowing everything to cool down.
4) SCRATCH FEATURES. New blocks: Pose (set all 12 servos in a single command), Gait (create a custom walking gait), Erase Recordings (blows away all scratch recordings in a single command). Record mode now truly works. You can record, in theory, all 60 button combinations. I have personally done 30 and all work fine! A "long tap" on a mode button, such as W1, will play the associated scratch commands, if any, or default to normal actions if not. A short click brings you back to normal functions.
Example: Program a long click on W1 to trigger custom gait commands for all 5 dpad buttons such that the robot leans backwards 30 degrees while walking. For example this would give you an advantage in Joust. In this case, you could program the special dpad button (the one above the four directional buttons) to sweep the robot back and forth by pivoting hips while leaning back, thus again in joust this would give you an easy way to try to knock off an opponents rider.
The gait command actually allows access to gaits not normally available on the gamepad, currently "ripple" gait but in the future more gaits will be selectable.
5) BUG FIXES. Numerous bug fixes are in this release, including several that affected certain Scratch blocks under some circumstances.
6) INTERNALS. Variable and function names were made more consistent, a new system for turning on different levels of debug was implemented (mostly in the gamepad code). All warnings were fixed, the code compiles clean. The only exception to this is that under the very highest level of verbosity (see Preferences in the arduino IDE) some of the libraries we use, such as SD, show warnings. But we can't really fix that. Scratch code was analyzed under a JSLINT style program and all warnings were fixed.
7) DEBUG MODES. Both robot and gamepad now immediately print their version number to the serial monitor on boot. This allows you to easily check what version you're running. The gamepad has three different debug modes for different purposes, this makes it much easier to turn on just the debugging you need if you wish to modify the software. All gamepad debug information is passed to Scratch in the java console so if you turn on debugging while using scratch you can actually see everything coming out of the gamepad.
KNOWN LIMITATIONS
There is one remaining known issue. If you use scratch recording to create a new long click motion, you can't then use that during a Gamepad record button session. We actually thought we had this working, but it turned out on more extensive testing that the attempt to make this work made the gamepad code unstable. The reason appears to be that every SD card file the software has open at once consumes 512 bytes of buffer memory. If two files are open at once (i.e. the scratch button recording is playing while the gamepad record feature is recording, two files) then that only leaves about 100 bytes of free ram, and depending on how deep the stack is or how many local variables are in use it is possible to run out of memory, which generally hangs the gamepad and then corrupts one or both of the SD card files that are in use.
For this reason, we had to suppress this. A quick hack to the state machine causes the gamepad to exit gamepad record mode if it ever sees an attempt to play a scratch long click recording. Vice versa, if a scratch longclick recording is in progress and the user clicks the "record" button (R1) then the record request will be ignored. Similarly, if scratch is in the process of recording a longclick function, attempts to hit the Play button (R2) or record button (R1) will be ignored.
So the limitation is: The gampad record/play feature can currently only record or play default functions on buttons, not special scratch functions.
There is a way to potentially fix this but it was too time consuming to attempt for this release, I didn't want to hold up the release for this one issue. (The fix is to write a special routine that copies bytes from the scratch file to the gamepad file but only keeps one open at a time, using a small local buffer to temporarily hold the data. But there are questions as to whether the SD card library is fast enough to make this practical, and the code is a bit tricky in that there are numerous places the state machine could attempt to open two files at once.)
Thanks to all the beta testers who gave us feedback, and if you find any issues or concerns with this new code please post here or privately email sup...@vorpalrobotics.com
Take care,
Steve Pendergrast
Vorpal Robotics, LLC
Steve Pendergrast
Jul 20, 2018, 8:45:20 AM7/20/18
to Vorpal Robotics Forum
One more thing I forgot to mention is that the scratch servo watchdog was successfully completed and is in V2. This means that if you write a scratch program that rams two legs into each other into a stall position, then the robot will detect this at a very low level of code and will back off the commanded positions just enough to avoid stall. The back-off applies equally to both legs.
It is possible for the legs to touch each other, but they won't press with any significant force.
I had to implement this using a linear approximation rather than doing the full blow trig required to actually detect a collision, as the trig version took too much codespace. It turns out that within the parameters of this robot, the linear approximation is darn close anyway (within a degree or two).
This was implemented because we had a case this summer of a camp using the hexapod with scratch. One student apparently wrote a program that stalled two legs against each other for an unknown period of time (it may have been 10 or more minutes). The result was that the bec overheated and burned out.
In any case, that should no longer be possible. It is of course still possible to stall motors against accessory port attachments, or other robots or obstacles during activities, so keep an eye out for stalls and don't let them continue for more than a few seconds. This will lengthen servo life.
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
0 new messages