changing the code in the MR-C3024

[sippy]

Can I confirm exactly what you have created here then.

I have been following the discussion for a while, congratulations on finally cracking it. I have tested the program uploading to my RN and it works great. It is just that I am slightly unclear as to what this is.

I am interested in compiling C code to be directly executed.

Looking at the assembler this is not the boot loader in the atmega128 as per the Atmel datasheets’ definition of bootloader, but the code that is executed after a reset(if you forgive the distinction between the two) and this handles the downloading of instructions from robobasic/script. After a reset it waits for a download signal, if none is received then execute the current program otherwise start storing the new program, is this all correct?

And the current assembler that you have posted will replicate the current functionality of the controller. Again am I on the right track?

if this is all correct then what is the way forward for uploading compiled C, to write a new boot sequence based upon what you have learnt?

Finally if a hex file were uploaded that did not give the correct responses to the download sequence would this then prevent the downloading of code via the robobasic interface and/or your program? So basicaly if we do upload the wrong thing have we created a new expensive door stop?

Sorry for the tirade of questions its just that you seem close and I am quite eager to start building some RN C libraries as soon as I know what is required and possible.

[i-Bot]

Good questions.

The file cboot.asm is a true bootlloader. It is used to load application software to the C3024. It is very rarely used ( once per year !) in normal Robobasic or Roboscript mode. The only time it is used is when there is a new release of application code (scode.asm), last version 2.5 in late 2005.

Robobasic and roboscript on the PC use a complex serial protocol to interface to the scode.asm application. Robobasic and Roboscript generate intermediate code for download (not the cboot download) to EEPROM in the C3024. The scode.asm application interprets this code to perform the robot functions. This includes an interrupt driven motion engine to perform the servo activity including the Gyros.

Take a look here for a description of the Intermediate code, serial protocol ,how this all works together. though these descriptions are in urgent need of update.

http://robosavvy.com/Builders/i-Bot/webfiles/
When we want to program directly in C or assembler, then we are actually changing the application, not just downloading intermediate code to EEPROM.

You are rightly concerned about the "doorstop" question, but as I said in my previous post, the risk appears small, since the bootloader is very difficult to change.

So how do you now program in C or assembler. Well the canvas is bare and you have over 60K of code space to be creative in !

I use AVR Studio and GCC exclusively for creating code and find it just fine. I do admit that my Robonova has a lobotomised processor, so I can use JTAG ICE for difficult interrupt routines. But that is not a necessity.

My starting point was to turn the existing scode.asm routines into reusable code which is callable from GCC. This means I can use the motion engine including gyro. This also meant that I could reuse Robobasic code by simple translation to C functions. I did describe this earlier in the forum.

I have posted a couple of files which should explain this, but I am away from home, so do not have many files with me.

http://robosavvy.com/Builders/i-Bot/upload.zip

Note: some ports may differ from standard due to my use of AD4.. AD7 as JTAG. Also I have problems here with the arrays in program memory, which I did not have at home.

Also; the above code is a direct cut of the Hitec/Miirobot code, so is their copyright. It is presented here for educational and research purposes only.

I hope this helps. I not, please ask more questions.

[i-Bot]

BTW. Do NOT just build and run the example I show. It move the first Servo through 180 degrees, which is outside the ormal limits for this servo. I was using this code for some servo tests.

[Bullit]

I've added some small improvements to i-Bot's RoboFlash.
It will now work automatically with either .bin or .hex files. It also remembers the comport setting and last file used setting.
The new version is here

i-Bot, I am having some trouble with the move command in the code you posted. It appears the motor commands at the begining of the code set the position to the zero position but after that the move command provides unpredictable results. PWM functions work well though. I'll continue to try to find the source to that problem. Perhaps as it was posted as an example it wasn't fully functional. Please enlighten me if you can

[i-Bot]

The code is not fully functional. It should be complete, but I did not debug all the ports, and functions, since I was working at the time on an Olimex board not the C3024. I did not check the Gyro code !

Now we have a proper loader to the C3024, I can go back and check the code. It is 3 months since I last worked with it, so you are now probably ahead of me.

I am not at home, and still have problems with the AVR Studio I installed on my travel PC. I will be back home next Thursday, so am of limited help to you till then.

If there are errors, then they are usually due to the adaptions I made to make the C language interface ( registers passed, registers changed where they should be protected). The core code functionality is the Hitec code, so should work OK, unless I cut any key parts !

I rather neglected this library development for two reasons, first due to uncertainty of the Hitec licence/copyright situation, and second that the engine has a slow interupt cycle (mSec) and spends long period in those interrupts. The timing issues are of little consequence in many appilcations, but were not suitable for my needs to provide a fast message based interface instead of the existing slow character based interface.

However, this library being so close to Robobasic, is a fairly straighforward transition where additional features need to be added. I can provide some support to efforts to complete this if it is considered of value to our community.

My new code is based around using the serial HMI interface on the Servo, making the C3024 into a 24 port UART, this means I can use a quick 25 microsec interrupts, so respond to serial or WLAN requests much faster. Some of the problem sensors/drivers have to go too. The remote control is a timing nightmare, as are the gryos. For the Gryo, I will probably go to a direct chip approach from Sparkfun via the AD inputs.

[DanAlbert]

This is long overdue, but I'll use my usual excuse "I have to work for a living."

I have uploaded a program I wrote that will reflash binary files, like payload2.5.bin, to the RoboNova-1.

I'm not the best microsoft windows programmer so don't flame me.
I tested it on a Windows 2000 platform and it seems to work.

It's called FreeLoader.exe

http://robosavvy.com/Builders/DanAlbert/

I'd be interested to know if it does the job or needs work.

I'll try to get my RoboNova OS working soon.

Dan

[sippy]

Thanks guys. Think I have got my head around how all the code fits together. Managed to get the example compiled and running.

One thing I noted was that the documentation for avr-gcc makefiles requires that .S files to be included must have a capital S otherwise they could be deleted as the compiler cleans up.

Also is there a possibility of starting to work on this stuff together in a subversion repository. I notice that robosavvy already has a sourceforge project run by limor, is it possible to get a subversion account from this and then start building up some common libraries in there?

[limor]

Hi sippy,

Give me your sourceforge user name and i'll add you to the project.

You can then add files through the subversion system as explained here.

[DanAlbert]

I think that is a good idea. I am willing to share what I have.

I have started a C/Assembly based O/S based on the ATMega128 in the C3024 configuration.
It uses the servos with the 1-2 ms PWM protocol. I did this so that you could mix in some non-digital servos.

All of my interface code (servos, speaker, RS232 and TWI) are interrupt based. So unlike RoboBasic you can walk, chew gum and whistle at the same time. (what a concept!)

The main thing I need to do at this time is figure out the best data structure to store moves in eePROM.

For now I think we only need a static model. But my plan is to add an IMU and allow dynamic corrections. I would like to create a limb processing structure that allows for IK declarations.

If anyone has any good ideas please post them so we can start hashing it out.

Dan

[sippy]

Ok limor I have created an account under the name sippy. Thanks.

I suppose we do need to hammer out exactly what is going in. Currently we have 2 different flash programmers here, are we going to choose one or the other for consistency or should we simply add both and let people choose. May be a good idea to merge them so that people have the option of either command line or GUI, also on a personal note a linux compatible version would be useful.

Do we also have 2 different sets of libraries being developed here too by Dan and ibot? Again how are we going to resolve this?

Most importantly ibot are you willing to share what you have, I presume since you have been sharing your code here that you are not opposed to it but are you willing to put it up for joint development? I presume that this step is going to require you to license this under some sort of open source/FSF license (probably LGPL) which you may not be willing to do, so not a totally easy decision.

[i-Bot]

I have no problem to share, contribute or license any software related to the loader, or work I am doing on my alternative HMI OS. I am not able to manage an opensource project on this software, since I do not have sufficient time available on a regular basis.

The latest version of the loader is in my file area as rflash2512.zip. this version reads .hex as well as .bin files. Also saves the file and port in the registry.

The situation with the source files based on the robobasic firmware is more difficult. I believe the copyright on this code is with Minirobots or Hitec since it is a dice and slice of their disassembled firmware. So unless they release the code under an appropriate license I think we unable to share for general use or to develop it further.

[DanAlbert]

The loader is not the important part here. I wrote my own because I may want to modify it to do other things. IE EEPROM or interpretive command loading.

I am more concerned with designing a better operating system for biped robots. Currently most "toy" bipeds use a Static model.

This must change!

We need to give them the ability to walk on uneven, incline and unstable surfaces.

Adding IMUs (gyros and accelerometers) and sensors to the current Static models don't help if the terrain is unknown. Experience has shown that they sometimes make things worse.

We need a dynamic self correcting system if this is going to work.
We have the hardware to do this NOW!
We lack the software.

My instinct is to build a simple multithreaded RTOS interpreter that will take high level commands. I think this is what RoboBasic was supposed to be. It was poorly implemented. It lacks the ability to do any Dynamic model programming!

Is there anyone that reads these posts that has done Dynamic model work?

[sippy]

I am mostly in agreement with you Dan that the OS is the important part. I presume that since we are proposing to start again from scratch then there should not be an issue with copyright since it will not reuse hitec code.

Also I am with i-bot that I do not have time to manage a full open source project, I was merely proposing that we all appear to be heading for the same goals( to produce a better OS) and currently are working separately. Would it not be better to place this stuff centrally and then work together, sourceforge just seems a convenient method of doing this as it is already available to us. I suppose you can still argue that it is an open source project however I am currently proposing it merely as a method to prevent us duplicating work and effort as opposed to starting a full blown project.

On a side note I appear to have reached a doorstop situation. I have been compiling and uploading code using your headers, example program and flash utility. The robonova now when turned on will give the 3E then quickly start streaming an endless string of E0’s. The only loader that will now write to it is freeloader, watching the interaction with a serial port monitor certainly seems to indicate that the program is being written and confirmed as it should be. However none of the binaries once uploaded seem to make much difference. Loading a basically blank template program will result in a stream of 3E’s which I presume is the controller continually resetting. And flashing either fake23.bin or payload2.5.bin does not seem to return their functionality…any ideas??

[DanAlbert]

To tell you the truth I have not uploaded binaries using either utility.

I have replaced the chip on my board with a new one that did not have the JTAG port locked. I use a JTAG interface to run under debug mode while I am testing my new software.

As soon as I get to the point where I have a usable O/S I will test the my flash utility. Because the bootloader was responding correctly I assumed (bad practice) that it was working.

When you use freeloader it initially displays the number of blocks in the bin file.
It writes that number of blocks and then pads the rest of flash memory with 0xFF

I'm not sure if I needed to do that.
Also I do not see any code in the bootloader that i-bot posted that would produce an 0xE0...Yet when loading payload2.5 I saw it on my analyzer before the last block came through. If the E0 is something in i-bots payload2.5 code then I need to know since I terminate on either block 0xff or if I see an 0xE0.

[limor]

Also I am with i-bot that I do not have time to manage a full open source project, I was merely proposing that we all appear to be heading for the same goals( to produce a better OS) and currently are working separately. Would it not be better to place this stuff centrally and then work together, sourceforge just seems a convenient method of doing this as it is already available to us. I suppose you can still argue that it is an open source project however I am currently proposing it merely as a method to prevent us duplicating work and effort as opposed to starting a full blown project.

sippy, you were also added to the sourceforge project, you can now create any hierarchy or file under the robosavvy project.
Lets put things into proportion, this is not the development of the next Linux or OpenOffice we are talking about a small set of source code files, binary files, documents etc.
Sourceforge is just a convenient way of storing the files in a very well managed central repository. It may also expose other people who frequent sourceforge to be interested in this topic. I'll be happy to put some 'order' into these files once they accumulate to a large enough number that demands policing. I'm sure you are all experienced with CVS or SVN and will be creating a logical directory hierarchy (for example: /C3024/freeloader/ or /C3024/RTOS/ ).



Also, I'm in agreement with Dan regarding the need to ditch the "open-loop sequencing + in-servo holding-position PID control" paradigm and replace it with an IK front-end and a more comprehensive IMU feedback speed control in the hidden back-end.
RoboSavvy is cooperating on exactly this type of development with researchers at Lisbon university's robotics and mechanical engineering dept. Currently Biloids are in use because using the dynamixel protocol it is possible to create comprehensive feedback control at 100hz without too much hacking.

So any questions regarding IK, Kalman filters or other fancy control loop can be answered by experts in this area.