2010 Kit

30 replies [Last post]
awright
awright's picture
Title: Roboticist
Joined: 07/06/2009
Posts:
BotPoints: 30
User offline. Last seen 13 years 11 weeks ago.

I feel your pain on the drift issues. Here's some thoughts on this topic:

  • I have no idea what the implemenation for the CBC is and cannot address that. However, BEMF as implemented by Rich LeGrand for the XBC was amazing. I think that the first use of this technique was done by Randy Sargent and Bill Bailey on our Mirosot robot soccer team in 1996. That was good, but Rich LeGrand's implementation for the XBC was much better. In fact, it's the best I've ever seen.

    As Jeremy said, quality of BEMF is dependent on motor quality and cleanliness of the motor signal. Low quality motors, long unshielded motor wires, and EMI (electromagnetic interference) all degrade performance.

    Unfortunately with the limited budget available for Botball kits it's not possible to buy really high quality motors without having to increase the kit price. That would exclude more teams, and unfairly impact those at schools in areas at the low end of the socioeconomic scale. The best solution to this would be to get high quality motor manufacturers to donate sufficient quantities of motors to Botball so that all teams could have enough for the drive wheels of their bots. Any volunteers?

    My memory is that for optimal performance the BEMF also needs to be specifically tuned for the properties of the motors being used. These properties vary between different types of motor (grey lego motors vs. white motors, for instance). They also may vary between different individuals within a given type (between different white motors in the same kit, for instance). I would guess this inter-motor variance is higher for low quality motors than for high quality ones too (lower quality -> lower tolerances -> higher variance).

    When we were originally working on rolling out the initial XBC library implementation, we thought about tuning the BEMF parameters for the different motors. However, this would have added significant complexity. The user would have to specify somehow which type of motor was plugged into each motor port. They would have to modify the software each time they reconfigured which motor was plugged into which motor port. If they forgot or got it wrong it'd be a subtle additional source of drift that could mess up performance in confusing ways. Also, it wasn't clear how much this would even help given the potential inter-motor variance problem.

    In the end, we just used a uniform set of parameters that was reasonable for the motors in the kit but not optimized for any of them. The effect of that decision was to accept that there would be some drift in return for the greater usability and decreased complexity compared to the "optimize for each motor type" approach.

    In contrast, the demo video Jeremy posted was the result of Rich LeGrand hand-tweaking the BEMF parameters for those particular motors. You'll also notice that the wires are short, and there's no other electronics nearby so EMI is probably lower than on a full bot. It's an amazing demonstration of what BEMF is capable of under ideal conditions. Don't be too disappointed that you have more drift than that.

    I suspect that it may be possible for a sufficiently motivated person to develop a motor calibration technique which allows the controller to determine better parameters for a given motor. Then, so long as a user was consistent about which motors they use in each motor port, they may get closer to optimal drift behavior.

    This may be a very hard problem, but I've been impressed so far by Botball participants' abilities to tackle such things. Note that it may also be the case that a given motor's optimal parameters may change over time and recalibration may sometimes be necessary. Figuring out if this is an issue and how much of an issue it may be would be part of this research project.

  • Encoders do drift. Particularly non-quadrature encoders, which is the best you could reasonably do with the old break-beam sensors. Trust me: you're better off with BEMF.
  • Gyros and compases sound like a good idea, but they're realistically likely to be more trouble than they're worth. They're not particularly accurate and are very sensitive to EMI and mechanical jitter -- particularly low end ones. The resulting angular errors integrate into position errors pretty fast. Even using high end ones, we had all sorts of trouble with them on the rovers I worked on at NASA.

    A combination of working to reduce BEMF drift and providing/leveraging environmental cues based on other sensors is likely a more lucrative and less frustrating path.

    That said, I'd be interested to hear the results if someone were to take one of the new phones with accelerometers, figure out how to log the data, and play with how usable it is if you strap it to the top of a Botball bot...

  • Hope this helps,
    Anne

Jeremy Rand
Jeremy Rand's picture
Title: Botball Youth Advisory Council
Joined: 04/03/2009
Posts:
BotPoints: 1168
User offline. Last seen 7 years 18 weeks ago.

Wow, that was an impressively detailed post... thanks for the info Anne! I do have one question. Regarding what you said about Rich hand-tuning that demo bot... that bot is running the haptic.cxx example, correct? If so, it looks to me like all Rich did was lower the P gain and zero all of the PWM values that were below a certain threshold, both of which reduce oscillation but don't seem to be particularly complicated code-wise. The anti-oscillation code is only 4 lines. Did Rich do something that I'm not aware of?

-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS

matthewbot
Title: YAC
Joined: 04/12/2009
Posts:
BotPoints: 94
User offline. Last seen 12 years 11 weeks ago.

Compasses shouldn't really drift at all, being an absolute measurement, they may just have bias and non-linearity. But they've been used in create projects to enhance the create's accuracy, and even with potential skew they claim its a big improvement:

http://www.instructables.com/id/SFAJM5JF5Y3YVPT/
http://createforums.irobot.com/irobotcreate/board/message?board.id=Creat...

They both had to work on calibration and sensor placement, but on the instructables at least the author claimed that moving the sensor a mere 4 inches above the creates motors eliminated most of the interference, which isn't bad at all.

--
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.

Albert Einstein

Project Quadcopter: http://quadcopter.wordpress.com/

KIPR Matthew
KIPR Matthew's picture
Title: KIPR Staff
Joined: 06/04/2009
Posts:
BotPoints: 154
User offline. Last seen 5 years 3 weeks ago.

Compasses are great, it you do not have any metal close by. There is a three axis accelerometer in the CBC, so you can measure velocity with a little math.

If there are any more general piece requests or input let me know!

Join the Botball folding at home team!
http://folding.stanford.edu/
Team 87314 "Botball"
Stats: http://folding.extremeoverclocking.com/team_summary.php?s=&t=87314

intelburn
intelburn's picture
Title: MiniBot
Joined: 07/02/2009
Posts:
BotPoints: 43
User offline. Last seen 9 years 22 weeks ago.

more languages added to the environment like remove cbcjava and cbclua and put them into KISS and add some new ones like C++, basic(as a joke), C#, more options to script, and officially add Create Script with a button on the CBC that says "Download Create Script".

We kick bot
JLCC

awright
awright's picture
Title: Roboticist
Joined: 07/06/2009
Posts:
BotPoints: 30
User offline. Last seen 13 years 11 weeks ago.

@Jeremy: If I understood properly, the motors in that demo are probably the same motors that Rich was using to develop his BEMF implementation in the first place. Developing that sort of thing requires that you determine various thresholds, gains, etc. experimentally. He naturally would tweak them to work as well as possible for what he had on hand, namely those particular motors.

I don't know whether or not he measured drift on a variety of other motors or not, or what he may have found. I only became aware of the issue while in Norman for the first Teacher Workshop where we used the XBC. It was a bit too crazy at that point to have a heart to heart talk with Rich about it...

Anne

stevenrobot
stevenrobot's picture
Title: NooBot+
Joined: 07/14/2009
Posts:
BotPoints: 16
User offline. Last seen 13 years 10 weeks ago.

More LEGO pins would definitely be nice. bricklink.com is a great place to pick up individual LEGO parts cheaply.
http://www.bricklink.com/search.asp?pg=1&q=4459&sz=10&searchSort=P
I found black friction pins selling for less than a cent each.
The camera this year was a pain to mount. After a couple of runs someone would inevitably bump the camera and we had to redo camera constants. We did come across the solution of wraping a vex beam around the camera and anchoring to the driving base. However, this does not seem like a elegant solution.
I think the Vex to Lego metal plates are a great idea. Make sure to include them in the new kit.
Please do not include Uglu in next year's kit.

Jeremy Rand
Jeremy Rand's picture
Title: Botball Youth Advisory Council
Joined: 04/03/2009
Posts:
BotPoints: 1168
User offline. Last seen 7 years 18 weeks ago.

Intelburn: I think most of those ideas are really best done as they are now: by teams innovating themselves rather than KIPR supplying everything a team could ever want. KIPR does not have the resources to support Java, Lua, BASIC, C++, C#, and Create OI Scripts. I know this; I interned at KIPR over the past 2 summers, and they simply did not have the staffing or money to help hackers. They like seeing students do this stuff on their own time (we won 2 Judges' Choice Awards at regionals and 2 Outstanding Conference Paper Submission Awards at GCER for that kind of stuff), but asking them to officially support this stuff is asking that they take the money out of something else (e.g. the kits would be smaller).

Besides that, I know that Matt, Braden, and I enjoy hacking stuff and developing new innovations, and that fun would be lost if KIPR handed everything to the teams pre-made. If you like hacking yourself, then hack yourself. If you don't like hacking yourself, then wait for teams to release things at GCER. Java, Lua, C++, Create OI Scripts, and all of the other Norman and Nease hacks have been released at GCER, and are ready for any team to have fun with. The only difference is that you contact Matt, Braden, and me for help rather than contacting KIPR. I'm always happy to help people on this forum or the Botballer's Chat. So by all means, hack away, just don't expect KIPR to have the ability to help you. That's why we have a Botball Community, right?

-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS

intelburn
intelburn's picture
Title: MiniBot
Joined: 07/02/2009
Posts:
BotPoints: 43
User offline. Last seen 9 years 22 weeks ago.

Give us an application that downloads code to the CBC without the use of KISS like (in IC) XportUtil. The reason is when KISS (or whatever you will call it next year) isn't working I can #include the headers needed and be on my way with Xcode.

We kick bot
JLCC

PiPeep
PiPeep's picture
Title: RocketBot
Joined: 07/19/2009
Posts:
BotPoints: 170
User offline. Last seen 8 years 28 weeks ago.

Intelburn: You can kinda do this (unofficially) with a custom flash drive script, or with a USB-Ethernet adapter and router (or computer with a dhcp server set up) via ssh/scp.

I looked at the official KISS-C source (here are the relevant parts: http://github.com/kipr/kiss/tree/master/targets/cbc/src/) for downloading code, and it seems to be too much trouble for me to code personally (although someone experienced with c/c++ and qt could do it easily) as it depends on qt (http://en.wikipedia.org/wiki/Qt_%28toolkit%29) for compression before sending to the device.

Also, could you make the program command-line and include a linux (probably just 32-bit x86) binary, or ensure it compiles easily? That would make it easier to script/use on linux.